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

[Brett Cannon]

On Fri, Sep 27, 2013 at 6:33 PM, Guido van Rossum <guido at python.org> wrote:

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

I don't see any issue with redirecting the discussion. python-tulip@ is
acting like a SIG for the module, so no real precedent beyond it not being
hosted as a mail.python.org list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130927/10f6e022/attachment.html>