On 2011-01-07 13:21:36 -0800, Antoine Pitrou said:
Ok, so, WSGI doesn't "already involve generators". QED.
This can go around in circles; by allowing all forms of iterable, it
involves generators. Geneators are a type of iterable. QED right
back. ;)
Right, that's why I was suggesting you drop your concern for Python 2
compatibility.
-1
There is practically no reason for doing so;
Of course, there is one: a less complex PEP without any superfluous
compatibility language sprinkled all over.
There isn't any "compatibility language" sprinkled within the PEP. In
fact, the only mention of it is in the introduction (stating that < 2.6
support may be possible but is undefined) and the title of a section
"Python Cross-Version Compatibility".
Using native strings where possible encourages compatibility, though
for the environ variables previously mentioned (URI, etc.) explicit
exceptional behaviour is clearly defined. (Byte strings and true
unicode.)
Just because you "managed to write" some piece of code for a
*particular* use case doesn't mean that cross-compatibility is a solved
problem.
The particular use case happens to be PEP 444 as implemented using an
async and multi-process (some day multi-threaded) HTTP server, so I'm
not quite sure what you're getting at, here. I think that use case is
sufficiently broad to be able to make claims about the ease of
implementing PEP 444 in a compatible way.
If you think it's easy, then I'm sure the authors of various 3rd-party
libs would welcome your help achieving it.
I helped proof a book about Python 3 compatibility and am giving a
presentation in March that contains information on Python 3
compatibility from the viewpoint of implementing the Marrow suite.
Python 2.x will be around for a long time.
And so will PEP 3333 and even PEP 333. People who value legacy
compatibility will favour these old PEPs over your new one anyway.
People who don't will progressively jump to 3.x.
Yup. Not sure how this is really an issue. PEP 444 is the /future/,
333[3] is /now/ [-ish].
- 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
