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.
Cool, glad to see the project is online somewhere, finally :).
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
