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 > 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
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 -- http://mail.python.org/mailman/listinfo/python-list
