Standard Asynchronous Python

[Oscar Benjamin]

On 2012-09-10, Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:
> On Sun, 9 Sep 2012 20:07:51 -0400, "Dustin J. Mitchell"
><dustin at v.igoro.us> declaimed the following in
> gmane.comp.python.general:
>
>> 
>> My proposal met with near-silence, and I didn't pursue it.  Instead, I
>> did what any self-respecting hacker would do - I wrote up a framework,
>> uthreads [4], that implemented my idea.  This was initially a simple
>> trampoline scheduler, but I eventually refactored it to run atop
>> Twisted, since that's what I use.  To my knowledge, it's never been
>> used.
>>
> 	So for your small attempt to hide an event-driven dispatcher, one
> has to load a massive event-driven library. Some years ago I tried to
> make sense of Twisted and failed badly. Maybe it makes sense to those
> raised on UNIX style select() (where practically anything that involved
> data transfer over some sort of channel could be tested -- but doesn't
> work as such on Windows where only network sockets can be used, file i/o
> needs to use a different call),
>> 

I think the idea behind the PEP is to facilitate modularisation of event
driven frameworks into dispatchers and libraries that are suitable for running
within dispatchers. When you say a 'massive-event driven library' I guess you
mean something liek Twisted. I don't have much experience with Twisted but
having looked at it a bit my impression is that it is so large because it
includes many components that are not essential for every user. I guess that
the reason for keeping those components in Twisted rather than as separate
projects is not so much because every user needs them but because many of them
are implemented in a way that makes them not much use outside of Twisted.

The idea that Dustin is proposing is that in the same way that a library might
declare a subset of its API to be thread-safe, and so usable with threading
frameworks, a library could expose a PEP-XXX compliant interface for use with
a PEP-XXX compliant dispatcher. If implemented that should facilitate the
creation of minimal dispatchers and minimal standard components that can run
within those dispatchers. This would mean that it wouldn't be necessary to
make massive event-driven libraries but rather smaller interchangeable
libraries. For example, it might facilitate the creation of a Windows-specific
dispatcher that would be able to use the best underlying Windows APIs while
also benefitting from any PEP-XXX compliant libraries that would work with any
other dispatcher.

>> As I get to work on the PEP, I'd like to hear any initial reactions to the
>> idea.

I don't have much experience with the event-driven frameworks but having made
a couple of simple scripts using gevent/Twisted my experience is that learning
to use these frameworks is hard, largely because of the number of framework-
specific concepts that are needed to make simple examples work. I would expect
that giving each framework a relatively standardised interface would make them
much easier to learn.

Oscar