[Web-SIG] Random thoughts

Greg Ward gward at python.net
Thu Oct 30 21:51:17 EST 2003

I'm just catching up on the archive for this list.  Some random

  * a new package, 'web', is definitely in order.
    "from web import cookies", "from web import http" just sounds right.
    (That contradicts Greg Stein's proposal in PEP 267, but I assume
    he's not strongly wedded to that.)

  * I'm all for stealing good ideas from other sources (eg. PHP,
    the Java servlet API), but I'm not keen on the exact semantics
    Simon has mentioned from PHP.  In particular, I hope no one is
    seriously considering global dictionaries called COOKIES or GET.

    Clearly, the Right Way is:



    (spelling and terminology yet to be decided; eg. I could live with
    it getcookie() and getformvar() ;-)

An aside: in the query string


what exactly are 'name', 'colour', and 'age'?  Are they form variables?
query variables? parameters? fields?  Is this specified anywhere?

(In Quixote's HTTPRequest class, they're called "form variables" --
hence get_form_var() -- but I've never been terribly thrilled with that
terminology.  At the moment, I like "query variables".)

  * on the fields-with-multiple-values issue: I'm with Steve Holden and
    David Fraser.  (I.e., the programmer should know which query
    variables expect multiple values, and the request object should
    always return a list for those variables.)  cgi.py is Dead Wrong
    here; the type of an object should be predictable from the code, not
    dependent on the HTTP client!

    (But I disagree with Steve on handling multiple values for a query
    variable that expects a single value: in that case, IMHO sloppy
    should be the default, and you should get the first value.  I don't
    want to guard every get_form_var() call with a "except KeyError" to
    avoid broken/malicious clients crashing the script!)

    (I've mentally toyed with funky types like Barry suggested, but I
    think that sort of context-sensitive trickery is unPythonic.  Just
    because you can do something doesn't mean you should.)

    Perhaps something like Quixote's form framework belongs in the
    standard library -- the Widget classes solve a lot of problems
    with handling HTML forms.  There's some out-of-date documentation

  * the "PATHINFO" variable is not CGI-specific.  Zope and Quixote are
    both utterly dependent on PATHINFO, and they're not tied to CGI.
    (There are strong connections, but you can run a Quixote app with
    mod_python, Medusa, or Twisted -- no CGI there!)

    Also, the Java servlet API has a getPathInfo() method, and Java
    servlets are most certainly not CGI scripts.

    "pathinfo" is just the part of the URL that the HTTP server doesn't
    look at.  ;-)

  * I oppose Simon Willison's practice of using the same variable
    in the "GET" and "POST" part of a request, but I will defend to the
    death his right to do so.  (But not in Quixote, where a narrower
    definition of what is Right, Good, and Truthfull prevails.)

Enough for now.  I still have lots of archive to read.  ;-(

Greg Ward <gward at python.net>                         http://www.gerg.ca/
And now for something completely different.

More information about the Web-SIG mailing list