Luke Arno wrote:
> If I understand you: if I tack some environ values on
> to my request object and the user changes those
> value on the request object, this must automatically
> be reflected in the environ. Is that right?
>
> If so, I disagree. If the user wants to change the value
> of something in the environ, she can do so. If not that
> is fine. I would rather say "no auto-magical updates!"
I'm not really clear what you're thinking. I guess I mean something
like this is bad:
class Request(object):
def __init__(self, environ):
self.environ = environ
self.params = parse_params(environ)
Now the request has a parsed form of the parameters (e.g., query
string), and if you recreate it then you'll have problems getting the
parameters again.
This particular case is the motivation for the form_vars spec.
>> In addition to this very minimal set of requirements for a request
>> object, the specification could have a kind of style guide for request
>> objects. No request object would have to conform, and it would not be
>> intended to ensure interoperability. The style guide would just be to
>> increase familiarity of developers when they encounter a new request
>> object.
>
> The whole point of a request object is to provide a more
> friendly and to-taste interface to cover the universal but
> decidedly (and necessarily) clunky WSGI interface. If
> we specify a style guide, many will feel compelled to
> conform to it. This seems counterproductive when the
> very purpose is to meet diverse preferences.
Well, if it's a style guide then no one is forcing you to follow it.
But if you don't care one way or the other, you can conform to something
just because.
I would assume the style guide would address the really
consistent/boring stuff, like form parameters and a few typical keys
like method and path_info.
If you want, you can provide multiple ways to get to the same thing, or
one way that doesn't fit the style guide; which will be typical when
backward compatibility is a concern.
> Though the similarity of request objects out there (note
> that I called mine "Yet Another Request Object") gives
> the appearance of a prime candidate for standardization,
> the subtle (or not) differences are very important to
> people in this area. It is sort of like the chair. It is a lot
> like the chair, actually: you are in it all day and it needs
> to be adjustable and fit just right.
>
> If this were a good candidate for standardization, I
> think WSGI would look a whole lot different.
I thought this way as well, but when the scope of the request object is
strictly confined to the WSGI environment I think it makes it a lot
easier. Not everyone will want to use that; for variety of small
reasons I think this is only going to be appealing to WSGIish
frameworks. But it's opt-in, so whatever.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
