[Web-SIG] PEP 444 / WSGI 2 Async

[Alex Grönholm]

08.01.2011 05:36, Antoine Pitrou kirjoitti:
> Alice Bevan–McGregor<alice at ...>  writes:
>> 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.  ;)
> Please read back in context.
>
>> There isn't any "compatibility language" sprinkled within the PEP.[...]
>>
>> Using native strings where possible encourages compatibility, [snip]
> The whole "native strings" thing *is* compatibility cruft. A Python 3 PEP would
> only need two string types: bytes and unicode (str).
>
>>> 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.
> It's becoming to difficult to parse. You aren't sure yet what the async part of
> PEP 444 should look like but you have already implemented it?
We are still discussing the possible mechanics of PEP 444 with async 
support. There is nothing definite yet, and certainly no workable 
implementation yet either. Async support may or may not materialize in 
PEP 444, in another PEP or not at all based on the discussions on this 
list and on IRC.
>>> 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.
> Well, I hope not too many people will waste time trying to write code
> cross-compatible code rather than solely target Python 3. The whole point of
> Python 3 is to make developers' life better, not worse.
>
>>>> 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].
> Please read back in context (instead of stripping it), *again*.
>
>
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/alex.gronholm%40nextday.fi