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
_______________________________________________
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
