On 2006 Nov 24, at 08:43, Christoph Haas wrote: > Frankly I'm unhappy with the 'cgi' module in the standard library. A > posting on the python-user mailing list made me rethink why web > programming is so painful for me in Python while it was easy in Perl > (while everything else was hard in Perl which is easy in Python). IMHO > Python deserves at least a good CGI implementation. And since I'm > used to > Perl's 'CGI' module I would at least expect the same functionality in > Python.
Keep in mind that packages in the Python standard library tend to have a slower development pace than packages that are available elsewhere, e.g. the packages listed at cheeseshop.python.org Because of this tendency, there are packages in the stdlib that have not changed in terms of interface or implementation for quite a while, with the exception of bugfixes or to add support for new syntax (like the new 'with' keyword in Python 2.5) I have a feeling that even if the "cgi3k" package comes with the Python 3.0 standard library, there will still be a "cgi" package kept around to support the large amount of code out there that relies on that package. > While reading what is already done and learning about this SIG I > found the > PEP333 that really scared me. I'm personally not interested in Python > acting as a web server. I'm used to run Apache and use CGIs that > deal with > stdin, stdout and environment variables. So my expectations are pretty > close to Perl's 'CGI' and 'CGI::Session' modules. But it sounds > like it's > pretty mandatory to use WSGI if I want to add any layer of > functionality. Don't get too scared by PEP333 :) Phillip J. Eby, PEP 333's author, seems unabashedly detailed and verbose in his writing style, but I think that's a very good thing for a specification that is being read and implemented by a large audience. If you want a gentler introduction to WSGI, try reading some of the stuff at http://wsgi.org/ -- especially in the "Learn WSGI" section. The interesting thing about WSGI is that you don't have to use Python as a web server to use it. Once you wrap your head around what WSGI gives you and what it doesn't, it is not too much different from using stdin/stdout pipes and environment variables at a low level. Many people do end up using Python as a web server in some regard when using WSGI though, since doing so can provide increased performance and makes the handling of persistent objects (such as sessions, database connections, etc.) easier. It is possible to write a WSGI application that can run either as a CGI script, or as a long-running process, connected to Apache via proxying or FastCGI for example. As far as the list of features that you desire from CGI, there are a growing number of WSGI applications that act as filters. See for example http://pythonpaste.org/ -- there are more resources on the wsgi.org site, and also on cheeseshop if you search for WSGI. Basically, you write your application as a WSGI application, then use third-party WSGI applications to "wrap" your application inside session handlers, form handling helpers, and so forth. > Should I just go ahead and create yet another framework and > increase the > chaos by joining the dark side? Or is there work going on where my > ideas > would fit in and where my revolutionary energy saves the world? I > would > love to see my Python skills - as average as they may be - create > something useful not only for me. I hope someone of you has enough > overview over the current activities to provide a little guidance. > Thanks > in advance. The concept of programmers, seasoned or not, contributing to a larger pool of useful software and ideas is one area where WSGI is making some traction. Ian Bicking puts it well in this entry of his: http:// blog.ianbicking.org/wsgi-update.html """ WSGI development can seem kind of plodding at times, because we're building up slowly from a low-level foundation. But as the tools emerge they work together really well; I think we're starting to see real returns from that process. ... """ For instance, you may find that something like httpy -- see http:// www.zetadev.com/software/httpy/ -- gives you an interface that is easier to grok than "bare-bones" WSGI. By using such software though, you will find that it still fits right in with other WSGI applications that offer useful services like session management, even if those apps are written using different techniques. And again, if written in such a way as to provide for it, a WSGI app can be served up as a CGI script :-) -- Matthew Scott [EMAIL PROTECTED] _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
