[Web-SIG] Future of WSGI

Sylvain Hellegouarch 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
>>     
> headers
>   
>> 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
> X-MyEnterprise-Metadata?
>   

x_myenteprise_metadata

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 [1] 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.

- Sylvain


More information about the Web-SIG mailing list