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

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

--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