[ OK. This is an old thread, but it's a new concern for me. I was researching to see what the current state of things was before making any public comments. I though I might as well provide this background to Dave Hastings, and also ask anyone involved in those earlier threads if there has been any more recent work on this that I might have missed. It looks like there was a flurry of discussion about this last fall but nothing seems to have come of it. ] On May 7, 2004, at 12:33 AM, Dave Hastings wrote:
[ ... ] The project that was decided upon, with the advice of the Professor, was to make a CGIpm python module that reflected CGI.pm for perl. We noticed that there is a current cgi module for python and even a cgipm module. These modules are very useful, but did not include all the functions that CGI.pm for perl provides. It turns out that my Professor really likes python and would have loved to see a CGIpm python module for python that was like the CGI.pm module for perl. [ ... ]
Dave, It's been a few years since I needed to do any cgi programming in Python. When I recently had to dig into it, I was SHOCKED to discover what a mess the current cgi module is. ( My second shock was when I looked at the source to try to figure things out, and discovered my name there at the top! ;-( It seems to be one of those things that just grew wild and didn't get much pruning. Mike McLay at NIST did the first version. I made some changes, but tried to keep backwards compatibility. Someone else came along and created a new set of interfaces, which both added and lost some functionality, but kept the older versions around for compatibility. ( I couldn't seem to get the new, improved version to do what I wanted, so I had to fall back on using the old compatability version! ) None of them seem very nice to use. Probably one of the few places where Python is 'uglier' than perl. And searching various Python archives, I find a history of similar complaints. Among the "Deferred, Abandoned, Withdrawn, and Rejected PEPs" is: PEP 222 (Dec 2000): http://www.python.org/peps/pep-0222.html which first proposes dumping the cgi module and starting over again:
The cgi.py module would be deprecated. (XXX A new module or package name hasn't been chosen yet: 'web'? 'cgilib'?)
... and a partial outline of a proposed interface. ( along with: Extended HTTP functionality and WEBDAV: http://www.python.org/peps/pep-0268.html ) In the Sept. 2003 Python-Dev archives: See the thread that begins with Subject: "[Python-Dev] Improving the CGI module": http://mail.python.org/pipermail/python-dev/2003-September/038128.html And the next month, a similar discussion picked up in the Web-SIG mailing list. See Web-SIG October 2003 Archives: http://mail.python.org/pipermail/web-sig/2003-October/thread.html See the many messages concerning "Form field dictionaries" , as well as several other threads in that months archive. As far as I can tell, all of those threads died out without any actual code being produced. However, they do give a good enumeration of what's wrong with the current cgi module and what's needed in a new module. Please let me know if there is any more current history I've missed in my search. ( I've been out of the python-dev loop for a while! ) I guess the Web-SIG is the best place for any further discussion. http://mail.python.org/mailman/listinfo/web-sig Dave: I'm not sure that following CGI.pm is the best possible design, but I'ld like to see what you're planning. If nothing else is happening on this front, I may be able to take a swing at it when I return from my vacation. -- Steve Majewski