On May 30, 2011, at 7:25 AM, Laurens Van Houtven wrote:

Hi!

I've just been in contact with Jim Fulton, who was previously mentioned in the context of developing this PEP, and he's okay with us taking over.

IIUC the PEP involves a few things:

A sane reactor abstraction/interface (although they probably won't like pulling in z.i.I) in the standard library which everything should be able to implement -- essentially twisted.loop's interface. This probably includes a Protocol abstraction too

Yes. Practically speaking these will have to be ABCs to fit into the Python stdlib idiom.

A simple, potentially insane implementation for it in the stdlib -- ideally twisted.loop, but probably something like asyncore-except-slightly-less-terrible

Yes.

A way to write code for it, probably involving @inlineCallbacks/monocle style yields

No.

In the interests of keeping the scope here as tight as possible, this is *not* a PEP about Deferreds or any of their equivalents, which are substantially more controversial. It is _just_ about an asynchronous networking API.

The most important parts are IProtocol/ITransport/IConsumer/IProducer. In order to do anything with these, of course, you need something somewhat like IReactorTCP/IReactorTime, but I would like to have those specified separately in the PEP, because the main interesting thing is just getting event-driven protocol logic based on a common API. The IReactorTCP analogue would just be a stub to get started, not a complete specification of every connection mode you might want. At the very least, there's SSL. Plus, even in TCP, there's a lot of complexity there which you need to modify if you want to have different connection/listening options (just look at the mess on the IPv6 ticket if you think this stuff is simple).

Convenience APIs like coroutine scheduling are definitely out of scope.

The idea here, as Glyph told me at Pycon, I believe, is that people can just write code that works on most backends. When they figure out the stdlib thing suck^H^H^H^Hdoesn't satisfy their requirements, we can just say "hey, it's okay, you can just replace the reactor reactor you have now with the twisted one and you will get all sorts of wonderful magic to play with".

In addition, it would be a way for the stdlib to gradually start evolving towards protocol implementations which parse chunks that are fed to them rather than calling recv() and expecting to block.

Am I completely wrong here already or does that sound like a sane problem definition?

Close enough :).

Either way I'm planning to put the PEP draft up on github (actually, I already have). Whether you like github or not, I think this feature: https://github.com/blog/844-forking-with-the-edit-button is just too amazing for writing a PEP as a community process to let pass.