[ 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4