Being unjust

[Kay Schluehr]

I'd be interested in what people think about bundling one of the
diverse Python webframeworks with the Python distribution which will be
"just there" as like Tcl/Tk+Tkinter for GUI-programming. Its not that I
don't trust people to make qualified decisions on their own or that I
actually believe in one single best solution. It's more a symbolic
action of bundling forces and attention.

Kay

 

[Fredrik Lundh]

I'd be interested in what people think about bundling one of the
diverse Python webframeworks with the Python distribution which will be
"just there" as like Tcl/Tk+Tkinter for GUI-programming.

if you can find one that's relatively stable, simple enough to enable beginners to
do simple things with just a little python code, can do simple stuff without needing
a full-blown DB, and can run as an ordinary CGI if necessary, I'm definitely +1.

(hmm. maybe "web.py" fits the spec? but that's more a library than a frame-
work, of course...)

</F>

 

[Steven D'Aprano]

I'd be interested in what people think about bundling one of the
diverse Python webframeworks with the Python distribution which will be
"just there" as like Tcl/Tk+Tkinter for GUI-programming. Its not that I
don't trust people to make qualified decisions on their own or that I
actually believe in one single best solution. It's more a symbolic
action of bundling forces and attention.

So long as I don't have to listen to the hordes of people arguing about
which framework gets preferred status, it sounds like a good move to me.

 

[Fuzzyman]

if you can find one that's relatively stable, simple enough to enable beginners to
do simple things with just a little python code, can do simple stuff without needing
a full-blown DB, and can run as an ordinary CGI if necessary, I'm definitely +1.

(hmm. maybe "web.py" fits the spec? but that's more a library than a frame-
work, of course...)

web.py has the great advantage that (allegedly) you can migrate apps
from CGI to FastCGI, mod_python, WSGI.

It hardly counts as stable of course - having just been released. +1 on
including it though ;-)

To be fair, it would be better to incldue a library rather than a
framework in the standard library.

There are a few fundamental "philosophy differences" in web apps which
makes it a bit of a religious war. This means getting something into
the standard library is likely to be the cause of intractable
discussions. *sigh*

I think Ian Bickings approach (ius this WSGI or paste ??) is to develop
a framework that componentizes the elements of web applications. (I
geuss it's a protocol as much as a framework). This means that you're
not locked into design decisions at the start of the game - and
components developed that follow the protocol can be easily re-used in
other projects.

Unfortuantely they (he ?) have made the API a blocking API (WSGI at
least is blocking) - this means it can't be used without threads. So
there is still a fundamental philosophy question here.

Other frameworks like Django and turbogears can't (as easily) share
parts of applications designed for the other framework. It would be
very difficult to jsutify including one over the other to include in
the standard library.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

 

[Paul Rubin]

I'd be interested in what people think about bundling one of the
diverse Python webframeworks with the Python distribution which will be
"just there" as like Tcl/Tk+Tkinter for GUI-programming. Its not that I
don't trust people to make qualified decisions on their own or that I
actually believe in one single best solution. It's more a symbolic
action of bundling forces and attention.

Yes, it's worthwhile and important to do this. It might not be
urgent; if the selection of available packages is still changing
rapidly then the right thing to do might be sit and wait temporarily.
But including a package should definitely be on the to-do list.
There should also be a dbapi package bundled.

 

[Fredrik Lundh]

web.py has the great advantage that (allegedly) you can migrate apps
from CGI to FastCGI, mod_python, WSGI.

It hardly counts as stable of course - having just been released.

given the amount of "I just updated and nothing works" messages
I see in certain framework foras, web.py is probably about as stable
as anything else...

</F>

 

[Adrian Holovaty]

web.py has the great advantage that (allegedly) you can migrate apps
from CGI to FastCGI, mod_python, WSGI.

This isn't an advantage of web.py over other frameworks. You can do the
same thing with Django, because it has a WSGI backend; people run
Django with mod_python, FastCGI, etc. I believe the same flexibility
applies to TurboGears.

There are a few fundamental "philosophy differences" in web apps which
makes it a bit of a religious war. This means getting something into
the standard library is likely to be the cause of intractable
discussions. *sigh*

As much as I'd like to see the core bits of Django (which wouldn't
require a database or include other fancy high-level features) included
in the standard library, I do think it'd devolve into a religious war
inevitably. A better goal, I think, would be to add some WSGI code to
the standard library -- for instance, code that runs a development
server for a WSGI-compliant framework, etc. Perhaps wsgiref:
http://svn.eby-sarna.com/wsgiref/

Just my two cents,
Adrian

 

[Kay Schluehr]

This isn't an advantage of web.py over other frameworks. You can do the
same thing with Django, because it has a WSGI backend; people run
Django with mod_python, FastCGI, etc. I believe the same flexibility
applies to TurboGears.


As much as I'd like to see the core bits of Django (which wouldn't
require a database or include other fancy high-level features) included
in the standard library, I do think it'd devolve into a religious war
inevitably. A better goal, I think, would be to add some WSGI code to
the standard library -- for instance, code that runs a development
server for a WSGI-compliant framework, etc. Perhaps wsgiref:
http://svn.eby-sarna.com/wsgiref/

Just my two cents,
Adrian

I agree with Paul Rubin that integration is not very urgent and with
Fredrik that requirements should be strict but I do think that some
"core bits" are not sufficient. The intention of bundling a framework
does not imply that components should be combined to the next 600
Python webframeworks but that there is a clear recommendation in
particular for beginners in Python. By the way I would also bundle
SQLite although it is not the most fancy DB. It is sufficient for small
apps, easy to handle and easy to describe. It shouldn't be tedious for
book authors to include a chapter for a std-webframework in any
introduction to Python.

Kay

 

[Paul Boddie]

This isn't an advantage of web.py over other frameworks. You can do the
same thing with Django, because it has a WSGI backend; people run
Django with mod_python, FastCGI, etc. I believe the same flexibility
applies to TurboGears.

Generally, most frameworks now seem to offer *CGI, either via or in
addition to WSGI. (One could uncharitably refer to WSGI as one of the
*CGIs, I suppose.) Other server support generally seems to be a bonus,
although I note that some WSGI implementations are attempting to
support something more exotic than the *CGIs.

Meanwhile, the main thing web.py has going for it is brevity - it
otherwise seems like a fairly ad-hoc mash-up of various "full stack"
components whose standard library inclusion would probably leave many
other framework developers howling in protest (and not without reason,
either). And given that some in the Python community squeal when
software is made available to them under something other than a
permissive MIT-style licence, I would honestly wonder what those people
would make of web.py's licence.

As much as I'd like to see the core bits of Django (which wouldn't
require a database or include other fancy high-level features) included
in the standard library, I do think it'd devolve into a religious war
inevitably.

Here's my biased perception of the Web-SIG process, since any
standardisation discussion supposedly starts there: first, everyone
attempts to nail down request and response objects, reaching no
particular consensus; then, the WSGI specification gets discussed for
seven or eight months; then, everyone panics at the sight of the Rails
juggernaut [1]; finally, I unsubscribe, but the archives seem to
suggest a range of not-particularly-convincing attempts at moving the
original cause forward.

But with regard to the standard library, here's an interesting quote
from a Web-SIG posting back in 2004: "I suspect that most web
frameworks will bypass the 'cgi' module as much as possible; it's too
messy to deal with and too difficult to clean up." [2] Sadly, most
frameworks (in my experience in wrapping them up under a layer of
cleaner functionality) do use the cgi module in some way or other, and
I'd argue (and I believe always argued) that the best route forward
would be to wean everyone off using that module directly in
applications/frameworks and onto something more abstract and easier to
use, possibly whilst tidying up the cgi module and making sure it works
reliably for all the low-level parsing that it's still going to be
responsible for doing. Sadly, WSGI hasn't addressed this issue at all,
as far as I am aware: it just lets the frameworks battle it out at a
marginally higher level.

A better goal, I think, would be to add some WSGI code to
the standard library -- for instance, code that runs a development
server for a WSGI-compliant framework, etc. Perhaps wsgiref:
http://svn.eby-sarna.com/wsgiref/

I think I probably underestimate the importance of WSGI, since its use
seems to be quite widespread in the newer frameworks or
mega-frameworks. However, WSGI is only a small proportion of the
substance in the original Web-SIG mission: to make Web programming
easier and more standard in Python. Over two years on (plus however
many years the Python Web Modules list was being used), the standard
library hasn't moved very much in that direction, creating a not
insignificant obstacle to significant Python adoption, in my opinion.

Paul

[1] http://mail.python.org/pipermail/web-sig/2005-April/001205.html
[2] http://mail.python.org/pipermail/web-sig/2004-March/000503.html

 

[skip]

Kay> The intention of bundling a framework does not imply that
Kay> components should be combined to the next 600 Python webframeworks
Kay> but that there is a clear recommendation in particular for
Kay> beginners in Python.

That's the rub though. There are lots of ways to approach web app
frameworks. They all have their pros and cons. Deciding on one to ship
with Python will likely be a significant challenge.

Skip

 

[Paul Rubin]

That's the rub though. There are lots of ways to approach web app
frameworks. They all have their pros and cons. Deciding on one to ship
with Python will likely be a significant challenge.

There are maybe a half dozen plausible candidates. The first thing to
do is ask the authors whether they'd WANT their framework to be
shipped with Python. If exactly one says yes, that makes the choice simple.
Either way, that question should narrow it down some.

 

[skip]

Paul> There are maybe a half dozen plausible candidates. The first
Paul> thing to do is ask the authors whether they'd WANT their framework
Paul> to be shipped with Python. If exactly one says yes, that makes
Paul> the choice simple. Either way, that question should narrow it
Paul> down some.

Even your technique narrows the list of candidates down to one, that doesn't
solve the problem. There is a certain "stamp of approval" implicit with
inclusion in the standard library. It's thus a fairly important decision to
get at least approximately right.

Skip

 

[Paul Rubin]

Even your technique narrows the list of candidates down to one, that
doesn't solve the problem. There is a certain "stamp of approval"
implicit with inclusion in the standard library. It's thus a fairly
important decision to get at least approximately right.

Yes, but something completely unsuitable shouldn't be on the list in
the first place. The main point is there aren't a million packages to
worry about, there are a handful, and that can probably be quickly
narrowed down to even fewer. Once that's done, the remaining
candidates can be considered in more depth.

 

[Kay Schluehr]

This isn't an advantage of web.py over other frameworks. You can do the
same thing with Django, because it has a WSGI backend; people run
Django with mod_python, FastCGI, etc. I believe the same flexibility
applies to TurboGears.

Generally, most frameworks now seem to offer *CGI, either via or in
addition to WSGI. (One could uncharitably refer to WSGI as one of the
*CGIs, I suppose.) Other server support generally seems to be a bonus,
although I note that some WSGI implementations are attempting to
support something more exotic than the *CGIs.

Meanwhile, the main thing web.py has going for it is brevity - it
otherwise seems like a fairly ad-hoc mash-up of various "full stack"
components whose standard library inclusion would probably leave many
other framework developers howling in protest (and not without reason,
either). And given that some in the Python community squeal when
software is made available to them under something other than a
permissive MIT-style licence, I would honestly wonder what those people
would make of web.py's licence.

As much as I'd like to see the core bits of Django (which wouldn't
require a database or include other fancy high-level features) included
in the standard library, I do think it'd devolve into a religious war
inevitably.

Here's my biased perception of the Web-SIG process, since any
standardisation discussion supposedly starts there: first, everyone
attempts to nail down request and response objects, reaching no
particular consensus; then, the WSGI specification gets discussed for
seven or eight months; then, everyone panics at the sight of the Rails
juggernaut [1]; finally, I unsubscribe, but the archives seem to
suggest a range of not-particularly-convincing attempts at moving the
original cause forward.

But with regard to the standard library, here's an interesting quote
from a Web-SIG posting back in 2004: "I suspect that most web
frameworks will bypass the 'cgi' module as much as possible; it's too
messy to deal with and too difficult to clean up." [2] Sadly, most
frameworks (in my experience in wrapping them up under a layer of
cleaner functionality) do use the cgi module in some way or other, and
I'd argue (and I believe always argued) that the best route forward
would be to wean everyone off using that module directly in
applications/frameworks and onto something more abstract and easier to
use, possibly whilst tidying up the cgi module and making sure it works
reliably for all the low-level parsing that it's still going to be
responsible for doing. Sadly, WSGI hasn't addressed this issue at all,
as far as I am aware: it just lets the frameworks battle it out at a
marginally higher level.

Funny reading !

I don't want to know what happens when the BDFL gets hitten by a bus

A pro pos BDFL. Citing his recent blog entry on Artima seems to
indicate that "religious wars" will sooner or later be inevitable:

"I actually don't think Google uses Zope (contradicting my own
statement above! .

I just spoke to Mark Shuttleworth who also expressed concern about the
lack of a "de-facto standard" Python web framework. I hope to be
working on this issue somewhat, but it'll take a long time, and I doubt
it'll involve open-sourcing Google code that is curently proprietary."

From: GvR: Re: Python Status Update Posted: Jan 13, 2006 4:30 PM

http://www.artima.com/forums/flat.jsp?forum=106&thread=143947

 

[Fuzzyman]

There are maybe a half dozen plausible candidates. The first thing to
do is ask the authors whether they'd WANT their framework to be
shipped with Python. If exactly one says yes, that makes the choice simple.
Either way, that question should narrow it down some.

Which ones do you see as suitable candidates for inclusion in the
standard library ?

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

 

[Paul Boddie]

There are lots of ways to approach a full Web application architecture,
but down at the bottom of the stack there isn't exactly too much
variation in what goes in and what comes out. Unfortunately, the debate
on request and response objects trespassed on the territory of what
existing frameworks do, and things like whether get_fields should
return a mixture of GET and POST request parameters distracted from
standardising on something. (Hint: at the bottom of the stack, you
don't want magic stuff like parameter merging going on - leave that to
something else if someone finds it hard to break some PHP habit or
other.)

As I said in another response to this thread, WSGI did attempt a degree
of standardisation but only by avoiding most of the hard or contentious
issues: not a particularly great result of two years discussion, in my
opinion.

There are maybe a half dozen plausible candidates. The first thing to
do is ask the authors whether they'd WANT their framework to be
shipped with Python. If exactly one says yes, that makes the choice simple.
Either way, that question should narrow it down some.

I don't understand why people want the python to swallow some
hippopotamus whole. The "winner takes all" (ie. "now everyone will
submit to my favourite framework - it is the one true way!") attitude
is precisely what keeps any kind of progress permanently stalled. I can
understand why people want GvR to make a pronouncement just to move the
debate forward (or rather to kill the debate and conjure up a result),
but such a pronouncement is more likely to result in yet another Zope
situation: there's the "one true way" that increasing numbers of people
object to, and then there's the chaos alongside it that has always been
there.

Paul

 

[Magnus Lycka]

if you can find one that's relatively stable, simple enough to enable beginners to
do simple things with just a little python code, can do simple stuff without needing
a full-blown DB, and can run as an ordinary CGI if necessary, I'm definitely +1.

(hmm. maybe "web.py" fits the spec? but that's more a library than a frame-
work, of course...)

For a long time, I used to think that software always belonged
to one of these two groups:

1. Easy to get started with, but doesn't work very well when you
get beyond trivial applications. E.g. MS Access and VB etc.

2. Works well for tough, real world applications, but with a much
higher threshold in the beginning. E.g. Oracle and C++ etc.

(Well, there was obviously completely useless software that was
neither easy nor scalable.)

Then I stumbled over Python, and realized that it doesn't have
to be like that... But that doesn't mean that all software written
in Python has this best-of-both-worlds quality. The plethora of web
kits for Python seems to suggest that noone wrote the "Python" of
Python web kits yet. (On the other hand, if my reasoning here was
sound, I guess everybody would program Python now...)

A type 2 application wouldn't be very helpful in the std lib, and I
think the initial complexity of many of these frameworks or libraries
stem from having grown from something small and simple into something
more featureful, but also relying on third party libraries and external
resources such as databases.

On the other hand, we don't want a type 1 application, or something
that's small and easy to understand simply because it's an immature
product on its way to become a type 2 application.

Maybe the right thing to put into the std lib is the core of one of
the fullblown toll kits. That might require some serious surgery.
Even with web.py, there is some work to get rid of Cheetah
dependencies by writing a replacement. If sqlite would also go
into the stdlib, I guess a std lib web.py should also be adapted
to that, otherwise the db thingies should just be pulled out.

If we look at Zope, It's only now, in Zope 3, after many years and
God knows how many development hours, that we start to see a more
mature, componentized struccture where different parts are usable on
their own and pieces can be unplugged and replaced with something
else.

 

[Ian Bicking]

I'd be interested in what people think about bundling one of the
diverse Python webframeworks with the Python distribution which will be
"just there" as like Tcl/Tk+Tkinter for GUI-programming. Its not that I
don't trust people to make qualified decisions on their own or that I
actually believe in one single best solution. It's more a symbolic
action of bundling forces and attention.

I'm coming in a little late here, but I'll say that I don't think this
makes any sense at this time. The Python web framework world this year
looks totally different from what it looked like last year. It might
be another year before Python 2.5 comes out. And who knows how long
after that for the next release. That development timeframe doesn't
match up at all. Not just kind of doesn't match up, but isn't even
vaguely close.

WSGI is stable, and perhaps some things directly related to that could
go in. A WSGI HTTP server (probably based on SimpleHTTPServer) could
go in. Maybe also a CGI version, maybe a forking version, maybe even
FastCGI and SCGI. That wouldn't be bad, but it won't be a great
benefit either. Normal people don't program directly to WSGI. So the
person has to install other libraries to get by, at which point they
might as well install the HTTP and other servers too.

easy_install helps make it viable to install lots of things, and the
benefits from that model extend well beyond web frameworks, and lets
people work on their own timescale instead of relying on the
understandably slow release schedule of Python itself. I think the
standard library is only appropriate for solved problems, where the
area is well understood. Just look at how much time it took to get
decimal and datetime in, both of which cover *very* well understood
areas.

Ian

 

[floydophone]

Here's what I think should go in the standard library:

- A set of battle-hardened WSGI gateways (CherryPy's WSGI server,
ISAPI-WSGI, mpcp, PEP-333's CGI gateway, flup's fastcgi and scgi
support). I think that if we included a WSGI app server with a snazzy
administration user interface (ala ColdFusion), it would be a pretty
cool thing to have.

- Defined WSGI middleware API for common components of many web
frameworks. For example, most frameworks need to map a request to a
piece of code somewhere. Many need to use a "pull" templating model.
Many need to load configuration values, etc. Web-sig should define an
API and a set of environ WSGI keys to implement all this functionality
in a pluggable manner. I made a stab at that here:
http://subway.python-hosting.com/wiki/Genweb

-peter hunt

Kay Schluehr skrev: