[Web-SIG] Re: Bill's comments on WSGI draft 1.4
Ian Bicking
ianb at colorstudy.com
Thu Sep 2 07:48:56 CEST 2004
Phillip J. Eby wrote:
> At 06:07 PM 9/1/04 -0700, Bill Janssen wrote:
>
>> 1. The "environ" parameter must be a Python dict: I think subclasses
>> should be allowed. A true subclass supports all methods of its
>> ancestors, so the rationale presented in the back of the PEP for
>> excluding them doesn't hold water. I think the appropriate check
>> would be to see if the returned class is a subclass of the "dict"
>> class. That is, "isinstance(e, dict)" should return True.
>
>
> Paradoxically, allowing subclasses eliminates the usefulness of allowing
> subclasses. Presumably, the purpose of using a subclass is to provide
> some extended behavior, e.g. as an attribute/method, or as a byproduct
> of requesting particular keys or values. In both cases, these extended
> behaviors would be destroyed the minute that a piece of middleware
> decides to use its *own* dictionary subclass.
I agree strongly with you on this. Subclassing built in types is almost
only useful for showing off clever tricks and distracting people who
want to change the language. Code constantly contains assumptions that
you can recreate built in types from their components, and then you lose
the subclass. I also don't see any advantage, beyond theoretical. Any
attempt to leverage a subclass is just as likely to cause problems as be
a help.
>> 9. There should be a non-optional way of indicating the URL scheme,
>> whether it is "http", "https", or "ftp". I'd suggest "wsgi.scheme" in
>> the environ.
>
>
> I rather like this, although I don't at all see how FTP gets into this.
> What the heck would CGI variables for FTP look like, I wonder? Anyway,
> it's handy for "http" and "https" at the very least. I'd prefer
> "wsgi.url_scheme" for the name, though, as it's otherwise a somewhat
> ambiguous name.
This sounds good to me too. I wanted HTTPS=on to be required, but
wsgi.url_scheme would be more general anyway.
It's pretty easy to imagine translating FTP to CGI variables, really.
The requested URL (SCRIPT_NAME+PATH_INFO) is the file you are getting or
putting, the REQUEST_METHOD is maybe GET or PUT (or maybe STOR and RETR,
but GET and PUT would be more natural). Most of the other commands map
to WeDAV methods. Obviously the server has to keep track of some state,
but typically that state is boring to the application anyway. But
that's all an aside. I can imagine mailto as well, when you pipe email
to your application.
--
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG
mailing list