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
Kay Schluehr wrote:
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
On 22 Jan 2006 20:35:17 -0800, Ian Bicking [EMAIL PROTECTED] wrote:
understandably slow release schedule of Python itself.I think thestandard library is only appropriate for solved problems, where the
area is well understood.Just look at how much time it took to getdecimal and datetime in, both of
Fredrik Lundh wrote:
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
Paul Boddie wrote:
Adrian Holovaty wrote:
Fuzzyman wrote:
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
Paul Rubin wrote:
[EMAIL PROTECTED] writes:
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.
Paul Rubin wrote:
[EMAIL PROTECTED] writes:
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 lots of ways to approach a full Web
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
Kay Schluehr wrote:
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
On Wed, 18 Jan 2006 03:27:56 -0800, Kay Schluehr wrote:
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
Fredrik Lundh wrote:
Kay Schluehr wrote:
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
Kay Schluehr [EMAIL PROTECTED] writes:
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
Fuzzyman wrote:
(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.
Fuzzyman wrote:
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,
Adrian Holovaty wrote:
Fuzzyman wrote:
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
Adrian Holovaty wrote:
Fuzzyman wrote:
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
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
[EMAIL PROTECTED] writes:
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
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
[EMAIL PROTECTED] writes:
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
I would prefer to see acore gui library that has a dom like structure and the core lib doesn't really define the interface but only serves as an interface to other interfaces.
For example, a button class in this library will work like this :
b = Button('Submit')
b.setStyles(
21 matches
Mail list logo
