Re: PEP 444 / WSGI 2 Async
Alice Bevan–McGregor <alice-h+KYGxXtFYrqlBn2x/[email protected]>
| Newsgroups | gmane.comp.python.web |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org