What do you want in a new web framework?

[emrahayanoglu]

Hello Everyone,

Now, I'm working on a new web framework. I tried many test on the other
programming languages. Then i decided to use python on my web framework
project.

Now i want to listen all of you. What do you want in that web
framework(Easy use of Database, Easy use of XML, GUI Designer, etc...)?

I'm wating your answers. Thank you for all answers...!

King Regards,

Emrah Ayanoglu

 

[Marc 'BlackJack' Rintsch]

Now, I'm working on a new web framework. I tried many test on the other
programming languages. Then i decided to use python on my web framework
project.

Now i want to listen all of you. What do you want in that web
framework(Easy use of Database, Easy use of XML, GUI Designer, etc...)?

I'm wating your answers. Thank you for all answers...!

Don't think that yet another Python web framework is really needed.

Ciao,
Marc 'BlackJack' Rintsch

 

[Paul Boddie]

Don't think that yet another Python web framework is really needed.

Why not? I know that some people are probably basking in the glory of
supposedly having their favourite framework recently blessed by the
BDFL, whilst others lament the almost unfair rejection of their own
framework on possibly dubious grounds by the very same person (thus
seeing their "winner takes all" strategy backfire totally), but open
source and various other network-effect movements benefit from lots of
people trying different things (the "scratch your own itch"
observation) rather than everyone gathering together for one big
strategy meeting.

Certainly, I'd recommend against anyone starting out on such a project
without having at least looked at the state of the Web frameworks scene
[1] and Python Web programming in general [2] (a resource which I've
recently updated in order to remove a degree of incoherency introduced
over the years), but apart from some Zope-based tools, I haven't seen
much GUI-designer-friendly stuff in the Python frameworks scene, for
example, nor does XML (in its widest W3C sense) seem to be
well-integrated into most frameworks (4Suite and some other less hyped
frameworks aside).

So it's not just a case of picking one of the more popular
frameworks-du-jour, especially since many of them seem to have their
own wheel-reinvention tendencies despite protests to the contrary.

Paul

[1] http://wiki.python.org/moin/WebFrameworks
[2] http://wiki.python.org/moin/WebProgramming

 

[hardemr]

Hello Everyone,

I've just read all of the answers. Most of yours said that there are
many web frameworks ,so it is nonsense to make a new web framework in
python.

Now I'm using and testing all of the frameworks in python also asp.net,
jsp and java servlet, perl web frameworks and ruby on rails. Some of
them have good positive points like that asp.net have gridviews to show
data records, ruby on rails have ajax support, etc...
The framework that i'll make, includes most of the positive points of
the other frameworks. Maybe, it's a mix of web frameworks. I want to
use dojo toolkit for javascript in my framework, and make a gui
designer like Visual Studio and Sun Creator, etc...

After that, may be you'll change your mind. And i want to listen your
advices. Please feel free to say everything to me about framework. I'm
waiting your answers.

Best Regards,

Emrah
Ankara/Turkey

 

[ajaksu]

Hello Emrah
I'd love to have a good framework with focus on static-content.
Something simple and useful like rest2web
(http://www.voidspace.org.uk/python/rest2web/) that could parse some of
the many templates available and output nice (X)HTML+CSS. Bundle a
simple GUI and you have something very interesting.

hardemr wrote:
Maybe, it's a mix of web frameworks. I want to

use dojo toolkit for javascript in my framework, and make a gui
designer like Visual Studio and Sun Creator, etc...

How about skipping the framework and focusing on dojo + GUI? Choose a
target (templating + framework, or a couple of targets), build a Visual
Studio for AJAX and you'll be a hero. Hack wxScintilla and build
something with good template highlighting and WYSIWYG-ish preview and
you'll be very famous. Build a great framework and yours will be one of
the many

Wishing you good luck,
Daniel

 

[UrsusMaximus]

I've just read all of the answers. Most of yours said that there are
many web frameworks ,so it is nonsense to make a new web framework in
python.

Hardemr, I like Ajacksu's answer, with a twist. Please concnentrate on
writing a Visual Studio-like gui designer, and make it possible to add
your Visual Studio like gui designer to Django (and TurboGears, et al).


Leverage the hard work of others and the installed base; add your
functionality on top. Don't re-create the wheel, build your internal
combustion engine powered vehicle on top of the 4 wheels that already
exist! ;-))

Please...

Ron Stephens

 

[Eric S. Johansson]

Hardemr, I like Ajacksu's answer, with a twist. Please concnentrate on
writing a Visual Studio-like gui designer, and make it possible to add
your Visual Studio like gui designer to Django (and TurboGears, et al).

it only make sense if you are disabled (visual or upper limb). most if
not all web frameworks are "no cripples need apply".

why? mixed caps, mixed modes (i.e. html+python), crappy editors to
start. these few items have such a *huge* impact that it can mean the
difference between being able to do the job or not. if you want to make
a diff, make an IDE that works for the blind and the mobility impaired.
the work has been started but it needs labor (see voicecoder project).
second place to make a difference is to build a bridge between windows
and gnome at-spi so one can speak (NaturallySpeaking on windows) then
have the effect show up on linux.

but in the context of web frameworks, my hp friendly framework shows how
easy it is to make apps HP friendly. the framework is rtg except for
packaging (and some docs). (I'm having problems trying to understand
and speak the setup file at the same time.)

If you want specific examples handicap barriers, I'll tell you after my
new mic arrives and my hands stop hurting so much. my cost: this
message means 30-40 min timeout for the nerves to cool off.

--- eric

 

[Tim Roberts]

Why not? I know that some people are probably basking in the glory of
supposedly having their favourite framework recently blessed by the
BDFL, whilst others lament the almost unfair rejection of their own
framework on possibly dubious grounds by the very same person (thus
seeing their "winner takes all" strategy backfire totally), but open
source and various other network-effect movements benefit from lots of
people trying different things (the "scratch your own itch"
observation) rather than everyone gathering together for one big
strategy meeting.

Ordinarily, I think the "do it yourself" nature of Python is a great thing,
and I would never try to dissuade someone from reinventing something
themselves. However, in the case of web frameworks, I believe Marc is
fundamentally correct: the web framework proliferation in Python is
actually doing the language a huge disservice.

Consider Ruby. If someone asks, "I'd like to do a web site with Ruby, what
should I use?", the answer comes back loud, clear, and unanimous: Ruby on
Rails. If someone asks, "I'd like to do a web site with Python, what
should I use?", she gets 25 different answers. "Look at HTMLGen, Cheetah,
WebWare, CherryPy, Karrigell, Django, Pylons, Plone, Zope, TurboGears,
etc., etc.", none of which are pre-installed in the typical Linux
distribution. To the non-programming decision maker, that kind of response
makes Python look unprofessional -- a toy.

Now, please do not send me ugly emails accusing me of running down Python.
I've been a Python believer since 1.52. I've done web sites in at least 5
of the frameworks, and I even wrote one of the wiki pages that compares web
frameworks. However, it is only the fact that I *AM* a true Python
believer that gave me the patience and incentive to try 5 different
frameworks. If a corporate decision maker were involved, that would never
happen. Python would simply fall off of the list of options, and the job
would get done in PHP or Ruby on Rails.

I agree with Marc. PLEASE do not create "yet another Python web
framework." Let's pick one, and join together to turn it into the One,
True, Unquestioned Web Solution.

 

[Paul Boddie]

Consider Ruby. If someone asks, "I'd like to do a web site with Ruby, what
should I use?", the answer comes back loud, clear, and unanimous: Ruby on
Rails.

I actually believe that people in most buzzword shortlist situations
see Rails as being the name in the list of candidates, not Ruby - it's
somewhat like Zope being in the list rather than Python, or
Struts/Tapestry/Apache-project-of-the-month being in the list rather
than Java (albeit with a fairly warm corporate feeling that Java is
there underneath).

If someone asks, "I'd like to do a web site with Python, what
should I use?", she gets 25 different answers. "Look at HTMLGen, Cheetah,
WebWare, CherryPy, Karrigell, Django, Pylons, Plone, Zope, TurboGears,
etc., etc.", none of which are pre-installed in the typical Linux
distribution. To the non-programming decision maker, that kind of response
makes Python look unprofessional -- a toy.

Indeed. That's why, after enumerating the uncontrollably expanding list
of solutions for a time [1], I wanted to concentrate on showing the
viable options with all their differentiating features in the Python
Web Frameworks Overview [2]. Ultimately, that content was moved to the
python.org Wiki [3] and everyone got their chance to hype their pet
project - it became like a random set of links. Sure, everyone wants
everyone else to see their work, but there's a role in the community
for objective education about the right tool for the job rather than
either graphically showing the little fish tear each other apart, or
jumping on the bandwagon with the most momentum and hyping it to the
exclusion of everything else. In the latter case, the end result is to
promote the big fish to the bigger pool (that stuff about Rails, Zope,
Struts & friends above), creating another generation of "agile
frameworks".

[...]

I agree with Marc. PLEASE do not create "yet another Python web
framework." Let's pick one, and join together to turn it into the One,
True, Unquestioned Web Solution.

Let's say we go for front-runner "du jour", Django. I've looked at
Django, and I'll admit that parts of the core API are fairly well done
when compared to certain other frameworks. However, let's say that we
want to "do it right" whilst expressing our dissatisfaction with the
templating, noting that when doing XML-oriented templating (that's
HTML, XHTML, XML and so on) I prefer something which upsets my Web page
editor less than it already is. So we unplug the templating somehow and
offer other options which plug into whatever magic that exists in
Django to make everything work smoothly. Let's say we unplug the
database abstraction layer because it doesn't do everything we want,
either, noting that I don't have any strong opinions about Django's
object-relational mapper, but I am wary of Web frameworks which
apparently encourage a database installation just for "hello world"
even if it isn't strictly required from a technical perspective.
Ultimately, we end up in a situation that is described far better in
the following article:

http://www.cmlenz.net/blog/2006/08/the_python_web_.html

In my opinion, what has damaged the Python Web frameworks scene has
been the continual hype and land-grabbing, the refusal to cede ground
on even the most basic stuff ("my magic form request variables are
better than yours", even though the majority of such magic solutions
are lacklustre at best), and that continual sighting of a grand prize
that at best gives you a ticket to Zopeworld - you get your own
"business ecosystem" while everyone else starts working on the next
thing to undo you.

I'd like to hear suggestions on how some cooperation can be encouraged
above the WSGI level, which despite the fanfare didn't really give so
many good answers to those confused users looking for a solution. As
I've said often enough before, the abstract "paper comparison" of Web
frameworks evolved into WebStack [4] which was originally an exercise
in seeing just how different many frameworks are at the lower levels:
the answer, given that you can paper over them in that way, is
"different only in unhelpful ways but not irreconcilably so". One day,
the Python Web frameworks scene may grow up and realise this fact.

Paul

[1]
http://web.archive.org/web/20041011...ohosting.com/~pboddie/Python/web_modules.html
[2] http://www.boddie.org.uk/python/web_frameworks.html
[3] http://wiki.python.org/moin/WebProgramming
[4] http://www.python.org/pypi/WebStack

 

[Alex Martelli]

themselves. However, in the case of web frameworks, I believe Marc is
fundamentally correct: the web framework proliferation in Python is
actually doing the language a huge disservice.

Indeed, it has been truthfully observed that Python's the only language
with more web frameworks than keywords.

I have already suggested to the BDFL that he can remedy this situation
in Py3k: all he has to do, of course, is to add a LOT more keywords.


Alex

 

[Fredrik Lundh]

Indeed, it has been truthfully observed that Python's the only language
with more web frameworks than keywords.

recent research indicates that it has more web frameworks than comments
in the source code.

</F>

 

[Cliff Wells]

Ordinarily, I think the "do it yourself" nature of Python is a great thing,
and I would never try to dissuade someone from reinventing something
themselves. However, in the case of web frameworks, I believe Marc is
fundamentally correct: the web framework proliferation in Python is
actually doing the language a huge disservice.

I disagree. Even if most of the frameworks end up being nothing more
than research artifacts, the fact is they embody research. Without
research the Python web framework space will be forever relegated to
runner-up (and probably has-been at some point).

Consider Ruby. If someone asks, "I'd like to do a web site with Ruby, what
should I use?", the answer comes back loud, clear, and unanimous: Ruby on
Rails.

Or Wee. Or Nitro. Or Nemo. Or others that are surely to be written as
Ruby gains acceptance and experienced users capable of writing them.

If someone asks, "I'd like to do a web site with Python, what
should I use?", she gets 25 different answers. "Look at HTMLGen, Cheetah,
WebWare, CherryPy, Karrigell, Django, Pylons, Plone, Zope, TurboGears,
etc., etc.", none of which are pre-installed in the typical Linux
distribution. To the non-programming decision maker, that kind of response
makes Python look unprofessional -- a toy.

Ruby on Rails doesn't come preinstalled either. I don't think it's
appropriate (and apparently most Linux distros currently agree) to
install web programming frameworks by default.

I will add that at least a few distros offer TurboGears, Django and
Pylons as add-ons.

Now, please do not send me ugly emails accusing me of running down Python.
I've been a Python believer since 1.52. I've done web sites in at least 5
of the frameworks, and I even wrote one of the wiki pages that compares web
frameworks. However, it is only the fact that I *AM* a true Python
believer that gave me the patience and incentive to try 5 different
frameworks. If a corporate decision maker were involved, that would never
happen. Python would simply fall off of the list of options, and the job
would get done in PHP or Ruby on Rails.

Yes, because PHP has only one web framework too ;-)

I agree with Marc. PLEASE do not create "yet another Python web
framework." Let's pick one, and join together to turn it into the One,
True, Unquestioned Web Solution.

Yes, and for those of us who may not like your choice, we can move to
another language or write our own, so nothing will have changed.

I think the entire concept that Ruby on Rails is successful because it
happens to be the dominant solution on what was previously a practically
unknown language is just plain ridiculous. If that's the case then why
hasn't Eiffel taken over the world? Or Lua? Or Io?

No, the reason Rails is successful is due to being a decent, focused
product with *great* marketing (screencasts, anyone?).

We've had several good Python web frameworks for some time, but
practically zero marketing (except for Zope/Plone, which as it turns
out, weren't such great products, at least not for the "80% solution"
that Rails targets).

Also the fact that Ruby doesn't suck isn't hurting Rails any either. If
GvR wants to improve Python's status against Ruby, I suggest looking at
what people are *really* raving about in the Ruby world (despite how
they got there) and address those issues rather than getting sidetracked
with this nonsense.


Regards,
Cliff
--

 

[John J. Lee]

Hardemr, I like Ajacksu's answer, with a twist. Please concnentrate on
writing a Visual Studio-like gui designer, and make it possible to add
your Visual Studio like gui designer to Django (and TurboGears, et al).


Leverage the hard work of others and the installed base; add your
functionality on top. Don't re-create the wheel, build your internal
combustion engine powered vehicle on top of the 4 wheels that already
exist! ;-))

pyjamas!

http://pyjamas.pyworks.org/


Now would be a fantastic time to muck in and do as UrsusMaximus
suggests -- nobody on the pyjamas project is yet talking about such
things, but it's obviously an area that could make you very popular if
done well ;-)


John

 

[Hendrik van Rooyen]

"Alex Martelli" <[email protected]>


| ...
| > themselves. However, in the case of web frameworks, I believe Marc is
| > fundamentally correct: the web framework proliferation in Python is
| > actually doing the language a huge disservice.
|
| Indeed, it has been truthfully observed that Python's the only language
| with more web frameworks than keywords.
|
| I have already suggested to the BDFL that he can remedy this situation
| in Py3k: all he has to do, of course, is to add a LOT more keywords.
|
|
| Alex

*groan*

 

[Hendrik van Rooyen]

| Alex Martelli wrote:
|
| > Indeed, it has been truthfully observed that Python's the only language
| > with more web frameworks than keywords.
|
| recent research indicates that it has more web frameworks than comments
| in the source code.
|
| </F>

Aaaaargh!

 

[Paul Boddie]

I disagree. Even if most of the frameworks end up being nothing more
than research artifacts, the fact is they embody research. Without
research the Python web framework space will be forever relegated to
runner-up (and probably has-been at some point).

It's perhaps surprising that even in the areas of the software industry
that are focused on selling expertise by providing services, as opposed
to selling licences for some code, that the research aspect of
developing some software, along with the knowledge gained in the
exercise, is frequently ignored in favour of some mass of code that is
gradually approaching legacy status. Familiarity with the problem
domain is extremely useful, even if it produces no long-lasting product
such as a popular Web framework, and the mere knowledge gained in
producing something that perhaps no-one else wants to use can be
important in informing future decisions about adopting (rather than
developing) suitable frameworks, if nothing else.

[...]

Ruby on Rails doesn't come preinstalled either. I don't think it's
appropriate (and apparently most Linux distros currently agree) to
install web programming frameworks by default.

I think the comment about pre-installed frameworks either confused the
issue of availability with the default package selection in some
distros, or mistook some announcement/hype about Rails on Mac OS X as
being an indication of a wider trend.

[...]

No, the reason Rails is successful is due to being a decent, focused
product with *great* marketing (screencasts, anyone?).

Screencasts? Perhaps, like a great showman, they draw in the punters
effectively enough, but I'd rather developers concentrate on writing
decent documentation than stuffing the pipes of the Internet up with
multi-megabyte proprietary blobs showing some individual developing
"hello world" (and still having to practise slight-of-hand in order to
make it "slick" enough).

[...]

Also the fact that Ruby doesn't suck isn't hurting Rails any either. If
GvR wants to improve Python's status against Ruby, I suggest looking at
what people are *really* raving about in the Ruby world (despite how
they got there) and address those issues rather than getting sidetracked
with this nonsense.

First of all, I'd take the raving from the Ruby scene with a pinch of
salt, given the tendency of the blog personalities doing the raving to
breathlessly declare some kind of victory at every turn - as Steve
Holden once said, these people are good at the "don't mention the
weaknesses" style of marketing, and that's probably something various
Python Web framework developers have picked up quite effectively. I'd
rather the Python core developers stopped chasing shadows and looked at
the Python distribution in its entirety. Hopefully, the Python 3000
exercise will see its focus shift into really removing the artifacts of
legacy decisions in both the language and the library rather than
shoehorning more wishlist items into the language.

Paul

P.S. Wishlist shoehorning example: decorators plus annotations ("not
really for static typing, honest!") equals...

http://mail.python.org/pipermail/python-3000/2006-August/003034.html

It's possible that the example decorator in the above message
unintentionally communicates the cynical view of decorators, but the
spectre of multi-page "annotations" is still worth worrying about even
if you're a decorator fan. See other messages in that thread for some
of the ideas (and to bring forth that longing for simpler times).

 

[Peter Maas]

Indeed, it has been truthfully observed that Python's the only language
with more web frameworks than keywords.

I have already suggested to the BDFL that he can remedy this situation
in Py3k: all he has to do, of course, is to add a LOT more keywords.

Here is another remedy: he adds one of the frameworks to the standard
library

Peter Maas, Aachen

 

[Cliff Wells]

Cliff Wells wrote:

Screencasts? Perhaps, like a great showman, they draw in the punters
effectively enough, but I'd rather developers concentrate on writing
decent documentation than stuffing the pipes of the Internet up with
multi-megabyte proprietary blobs showing some individual developing
"hello world" (and still having to practise slight-of-hand in order to
make it "slick" enough).

Well, I think screencasts are pretty great for this type of thing.
Think about the primary complaint: "Which one do I choose?". It can
take a while to wade through the various documentation (or lack of),
install, do some basic tests, etc and the whole process can be pretty
wearing on a newcomer. A screencast on the other hand lets you lazily
sip coffee while you get a small feel for the framework. I think it
also shows what someone who *knows* the framework can do (which can be
nearly impossible to know when you're testing it yourself). The "20
minute wiki" screencast would be the "2 day trial and error" for someone
new to the framework.

[...]

Also the fact that Ruby doesn't suck isn't hurting Rails any either. If
GvR wants to improve Python's status against Ruby, I suggest looking at
what people are *really* raving about in the Ruby world (despite how
they got there) and address those issues rather than getting sidetracked
with this nonsense.

First of all, I'd take the raving from the Ruby scene with a pinch of
salt, given the tendency of the blog personalities doing the raving to
breathlessly declare some kind of victory at every turn - as Steve
Holden once said, these people are good at the "don't mention the
weaknesses" style of marketing, and that's probably something various
Python Web framework developers have picked up quite effectively.

Oh sure. And you have to also remind yourself that most of these guys
are coming from PHP where practically nothing sucks by comparison (and
there are *lots* of PHP people to convert).

But there are interesting things in Ruby (and Ruby 2 should take care of
lots of warts Ruby 1.8 has) that Python could learn from. All-in-all,
Ruby is mostly as good as Python in most ways and better than Python in
a couple key ways. Add marketing to that (whatever kind it happens to
be) and you've got the recipe for success.

When I suggest using Python to customers they tend to get nervous as if
it's some esoteric language that might disappear off the map next
weekend and is only known to 12 people. I shouldn't need to reassure
people that it is what it is: one of the most popular languages in use
today. That's the other kind of bad marketing that Python should avoid.

I'd rather the Python core developers stopped chasing shadows and looked at
the Python distribution in its entirety. Hopefully, the Python 3000
exercise will see its focus shift into really removing the artifacts of
legacy decisions in both the language and the library rather than
shoehorning more wishlist items into the language.

My single wishlist item (which will probably never happen) is actually
the *removal* of a single "feature": the distinction between statements
and expressions. Forget list comprehensions, ternary operators, etc.
You get them with no additional syntax in expression-based languages. I
played with Logix a bit (but sadly the project appears dead) and the
expression-based Python syntax it provides gives me goose-bumps.

At this point in my life, inertia keeps me with Python (it's "good
enough" and I lack the time and energy to convert to another language),
but there's little doubt in my mind that this distinction will
eventually force me elsewhere *wipes away tear*.


Regards,
Cliff

 

[Cliff Wells]

Here is another remedy: he adds one of the frameworks to the standard
library

That didn't help Tk maintain a monopoly on Python GUI toolkits.

Cliff

--

 

[Tim Roberts]

But there are interesting things in Ruby (and Ruby 2 should take care of
lots of warts Ruby 1.8 has) that Python could learn from. All-in-all,
Ruby is mostly as good as Python in most ways and better than Python in
a couple key ways.

....but you can't READ Ruby code. One of the things I like best about
Python is that, like Cobol, you can read Python code like prose (or poetry
and, for the most part, know what the code does, even without being a
Python guru. I have not had the same experience with Ruby. There are
special characters in there that make the program say something I can't
immediately discern.

To be sure, people whose opinions I trust (one of whom is Cliff Wells) have
said that Ruby is great, so I suppose I need to look again. I just haven't
had the same "aha!" experience that I had with Python.