On Fri, Sep 27, 2013 at 6:33 PM, Guido van Rossum <gu...@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-tu...@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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
