[Python-Dev] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio (original) (raw)

Guido van Rossum guido at python.org
Sat Sep 28 00:33:27 CEST 2013

I've been looking at my progress with Tulip and the 3.4 release schedule (PEP 429) and it looks like I will have to do some kind of sprint to get it into the release in time for beta 1, which is planned for Nov 24. Ideally I'd get it into alpha 4, which is scheduled for Oct 20 -- that's in about three weeks, and probably too tight.

Even Nov 24 is aggressive, because the PEP (PEP 3156) hasn't even been discussed formally, let alone accepted! Fortunately I'm pretty happy with most of the APIs defined in the PEP -- there are some holes but I expect no big changes at this point.

It's clear that the only way we can get this into the stdlib is to mark it as provisional, per PEP 411. That's fine with me. I expect that the kind of changes the code will see between the 3.4 and 3.5 releases are well within the bounds of the expectations set by that PEP -- while it is clear that everything is possible (even withdrawal), the most likely outcome is that the API will be extended or tweaked at most, and not significantly changed in a backward compatible way -- without completely ruling out that some part of the API may deserve a serious overhaul based on experience. That's exactly how I feel about Tulip.

I propose that the new library will be named asyncio. It would be odd if we kept the name tulip (stdlib modules rarely have "creative" names), and "asynchronous I/O" seems to cover the contents quite well.

I propose that we do the bikeshedding about the API on the python-tulip at googlegroups.com mailing list; I'm not sure what we would gain by holding the discussion on python-dev (although clearly we should report back here with important milestones in the review). I will post a message with the kick-off there.

I hope people will respect my choice of venue, and limit themselves to procedural issued on python-dev. E.g. it's fine to debate on python-dev whether I'm overstepping my BDFL authority here, or whether the proposed API is of sufficiently wide appeal. But I'd prefer to discuss e.g. the return type of start_serving() or the choice of yield-from over yield on python-tulip.

-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130927/cd769af7/attachment.html>

More information about the Python-Dev mailing list