Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio
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@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)
On Fri, Sep 27, 2013 at 6:33 PM, Guido van Rossum <guido@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@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.
On Sep 27, 2013, at 09:14 PM, Brett Cannon wrote:
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.
The PEP process even allows for this formally. Please add a Discussions-To header to PEP 3156. See PEP 1 for details. -Barry
On 9/27/2013 9:14 PM, Brett Cannon wrote:
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 <http://mail.python.org> list.
I'm sure I'm in the minority, but I'd like the discussion to take place on a python.org mailing list. I don't want to log in to a Google property, and I don't trust them with the mailing list archives. I know my voice counts less than active Tulip discussion participants, but now at least I feel better for having said something. -- Eric.
On Sun, Sep 29, 2013 at 5:40 PM, Eric V. Smith <eric@trueblade.com> wrote:
On 9/27/2013 9:14 PM, Brett Cannon wrote:
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 <http://mail.python.org> list.
I'm sure I'm in the minority, but I'd like the discussion to take place on a python.org mailing list. I don't want to log in to a Google property, and I don't trust them with the mailing list archives.
I know my voice counts less than active Tulip discussion participants, but now at least I feel better for having said something.
I wish you'd said something a looong time ago when it would have been easy to move the list. Even if we moved it now we'd have split archives. Also, I'm not sure where the paranoia comes from. FWIW I'm less worried about Google reading my personal email than about the python.org webmasters reading it. -- --Guido van Rossum (python.org/~guido)
On 09/29/2013 08:55 PM, Guido van Rossum wrote:
On Sun, Sep 29, 2013 at 5:40 PM, Eric V. Smith <eric@trueblade.com <mailto:eric@trueblade.com>> wrote:
On 9/27/2013 9:14 PM, Brett Cannon wrote:
> 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 <http://mail.python.org> <http://mail.python.org> list.
I'm sure I'm in the minority, but I'd like the discussion to take place on a python.org <http://python.org> mailing list. I don't want to log in to a Google property, and I don't trust them with the mailing list archives.
I know my voice counts less than active Tulip discussion participants, but now at least I feel better for having said something.
I wish you'd said something a looong time ago when it would have been easy to move the list. Even if we moved it now we'd have split archives. Also, I'm not sure where the paranoia comes from. FWIW I'm less worried about Google reading my personal email than about the python.org <http://python.org> webmasters reading it.
I wish I'd known the project would be such a success! I have a use for tulip, but not much time to offer development help currently, so I'll live with the outcome. I'd love to see it make 3.4. Eric.
It sounds like a reasonable approach to me. In terms of naming, would you consider "concurrent.asyncio"? When we created that parent namespace for futures, one of the other suggested submodules discussed was the standard event loop API. Cheers, Nick.
On Sat, 28 Sep 2013 15:59:05 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
It sounds like a reasonable approach to me.
In terms of naming, would you consider "concurrent.asyncio"? When we created that parent namespace for futures, one of the other suggested submodules discussed was the standard event loop API.
-10. Please, let's stop it. Regards Antoine.
On Fri, Sep 27, 2013 at 10:59 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
It sounds like a reasonable approach to me.
In terms of naming, would you consider "concurrent.asyncio"? When we created that parent namespace for futures, one of the other suggested submodules discussed was the standard event loop API.
Hm. I want the threading and event world to be very clearly separate and different, since accidentally combining them is disastrous. So the concurrent package is the *last* place where I want asyncio to live. (And I realize there is also some multiprocessing support in that package -- but it still uses threads to wait for things.) -- --Guido van Rossum (python.org/~guido)
On 29 Sep 2013 02:52, "Guido van Rossum" <guido@python.org> wrote:
On Fri, Sep 27, 2013 at 10:59 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
It sounds like a reasonable approach to me.
In terms of naming, would you consider "concurrent.asyncio"? When we
created that parent namespace for futures, one of the other suggested submodules discussed was the standard event loop API.
Hm. I want the threading and event world to be very clearly separate and
different, since accidentally combining them is disastrous. So the concurrent package is the *last* place where I want asyncio to live. (And I realize there is also some multiprocessing support in that package -- but it still uses threads to wait for things.) Makes sense to me! Cheers, Nick.
-- --Guido van Rossum (python.org/~guido)
So, with the naming settled (asyncio it is), and lots of other things still to do, I need a BDFL for PEP 3156. Any volunteers? If no-one volunteered I'll have to accept my own PEP at some point, but I don't really *want* to do that. -- --Guido van Rossum (python.org/~guido)
On Sun, 29 Sep 2013 09:54:39 -0700 Guido van Rossum <guido@python.org> wrote:
So, with the naming settled (asyncio it is), and lots of other things still to do, I need a BDFL for PEP 3156. Any volunteers? If no-one volunteered I'll have to accept my own PEP at some point, but I don't really *want* to do that.
Well, if you don't mind my slight pro-callback tropism, I'm definitely volunteering :-) Regards Antoine.
On Sun, Sep 29, 2013 at 10:16 AM, Antoine Pitrou <solipsis@pitrou.net>wrote:
On Sun, 29 Sep 2013 09:54:39 -0700 Guido van Rossum <guido@python.org> wrote:
So, with the naming settled (asyncio it is), and lots of other things still to do, I need a BDFL for PEP 3156. Any volunteers? If no-one volunteered I'll have to accept my own PEP at some point, but I don't really *want* to do that.
Well, if you don't mind my slight pro-callback tropism, I'm definitely volunteering :-)
I don't mind it, and if there's not too much objection from the community you've got the job! -- --Guido van Rossum (python.org/~guido)
On Sep 28, 2013, at 12:59 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
It sounds like a reasonable approach to me.
In terms of naming, would you consider "concurrent.asyncio"? When we created that parent namespace for futures, one of the other suggested submodules discussed was the standard event loop API.
+1 but up to guido
Cheers, Nick.
_______________________________________________ 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/jnoller%40gmail.com
On Fri, Sep 27, 2013 at 3:33 PM, Guido van Rossum <guido@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@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.
Sounds good. But once it's in stdlib, I think it would be proper to shift the discussion into the normal pydev channels (python-dev, issue tracker, etc.). Is this the plan? Eli
On Sat, Sep 28, 2013 at 9:07 AM, Eli Bendersky <eliben@gmail.com> wrote:
Sounds good. But once it's in stdlib, I think it would be proper to shift the discussion into the normal pydev channels (python-dev, issue tracker, etc.). Is this the plan?
Hadn't really thought about that. I think there's a precedent for aspects of Python that have their own mailing list (e.g. import-sig). Also, python-dev is usually pretty hostile about people asking usage questions -- there's no such taboo on the Tulip list. I can certainly see how you wouldn't want to have to look at multiple trackers. Possibly the Tulip tracker could be limited to discussion of the Python 3.3 backport that I hope to maintain in that project. -- --Guido van Rossum (python.org/~guido)
On 09/27/2013 11:33 PM, Guido van Rossum 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.
My guess is, a lot of people would be disappointed if Tulip missed 3.4. I suspect the community would rather we slip the beta a little if it meant it the difference between Tulip and no Tulip. I just hope you make it easy on me and beat the deadline ;-) Cheers, //arry/
participants (10)
-
Antoine Pitrou -
Barry Warsaw -
Brett Cannon -
Eli Bendersky -
Eric V. Smith -
Guido van Rossum -
Jesse Noller -
Larry Hastings -
Nick Coghlan -
Simon Cross