On 2011-01-02 11:14:00 -0800, Chris McDonough said:
I'd suggest we just embrace it, adding minor tweaks as necessary, until
we reach some sort of technical impasse it doesn't address.
Async is one area that 3333 does not cover, and that by not having a
standard which incorporates async means competing, incompatible
solutions have been created.
On 2011-01-02 12:00:39 -0800, Guido van Rossum said:
Actually that does sound like an opinion on the technical merits. I
can't tell though, because I'm not familiar enough with PEP 444 to know
what the critical differences are compared to PEP 3333. Could someone
summarize?
Async, distinction between byte strings (type returned by socket.read),
native strings, and unicode strings, thorough unicode decoding (moving
some of the work from middleware to the server), simplified call syntax
(no more start_response), and clear, consice language with easy
references via numbered lists.
The async part is an idea in my head that I really do need to write
down, clarified with help from agronholm on IRC. The futures PEP is
available as a pypi installable module, is core in 3.2, and seems to
provide a simple enough abstract (duck-typed) interface that it should
be usable as a basis for async in PEP 444.
There are parts I need to add back, of course. file_wrapper, examples,
rationale, and references being a few of the items not yet rewritten.
- Alice.
_______________________________________________
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
