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 09/29/2013 08:55 PM, Guido van Rossum wrote:

On Sun, Sep 29, 2013 at 5:40 PM, Eric V. Smith 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.

On Sat, 28 Sep 2013 15:59:05 +1000 Nick Coghlan 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 29 Sep 2013 02:52, "Guido van Rossum" wrote:

On Fri, Sep 27, 2013 at 10:59 PM, Nick Coghlan 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)

On Sun, 29 Sep 2013 09:54:39 -0700 Guido van Rossum 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 Sep 28, 2013, at 12:59 AM, Nick Coghlan 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 Sat, Sep 28, 2013 at 9:07 AM, Eli Bendersky 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 Mon, Sep 30, 2013 at 1:51 AM, Larry Hastings wrote:

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.

+1