[Web-SIG] Future of WSGI
sh at defuze.org
Wed Nov 25 18:30:18 CET 2009
Robert Brewer a écrit :
> Sylvain Hellegouarch wrote:
>> Personally, I would favor the idea that WSGI2 specifies the way
>> should be mapped to object attributes (e.g. Content-Type would become
>> content_type) and then let duck typing magic happen rather than
>> specifying a class from which to inherit for instance.
> How would you handle HTTP extension headers like
Now I get this only makes sense where the header is valid as a Python
identifier so more limited than a dict key for sure.
> Cook  might be appropriate to read here: "...abstract data types
> facilitate adding new operations, while [objects] facilitate adding new
> representations... Abstract data types define operations that collect
> together the behaviors for a given action. Objects organize the matrix
> the other way, collecting together all the actions associated with a
> given representation. It is easier to add new operations in an ADT, and
> new representations using objects."
But that's my point, we discuss request representation, not behavior.
> IMO, it's quite appropriate that we essentially use an ADT (a dict) at
> the lowest level, precisely because it constrains the representation.
> This is the essence of The Zen of CherryPy #8 "Subclassed builtins are
> better than custom types" (really, custom _classes_) and #9 "But builtin
> types are even better". People can then objectify those ADTs to their
> representational taste.
That's fine but looks redundant eventually in my opinion.
More information about the Web-SIG