PEP 3156 currently lists *29* proposed methods for the event loop API.
These methods serve quite different purposes and I think a bit more
structure in the overall API could help clarify that.

First proposal: clearly split the abstract EventLoop API from concrete
DescriptorEventLoop and IOCPEventLoop subclasses.�
The main benefit here is to help clarify that:
1. the additional methods defined on DescriptorEventLoop and
IOCPEventLoop are not available on all event loop implementations, so
any code using them is necessarily event loop specific
2. the goal of the transport abstraction is to mask the differences
between these low level platform specific APIs
3. other event loops are free to use a completely different API
between their low level transports and the event loop


I like the idea of splitting up the big interface, but could you clarify what would go into such subclasses? I.e. isn't the current EventLoop interface supposed to represent an interface all event loops will adhere to?
">

(original) (raw)

The concrete event loop methods are already separated in the PEP - they're just flagged as optional methods rather than distinct subclasses.

The rest I think actually do belong on the event loop, hence the suggestion to start just by rearranging them into those categories, without making the class hierarchy any more complicated.

--
Sent from my phone, thus the relative brevity :)

On Jan 21, 2013 12:18 AM, "Eli Bendersky" <eliben@gmail.com> wrote:
On Sat, Jan 19, 2013 at 6:34 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
PEP 3156 currently lists \*29\* proposed methods for the event loop API.
These methods serve quite different purposes and I think a bit more
structure in the overall API could help clarify that.

First proposal: clearly split the abstract EventLoop API from concrete
DescriptorEventLoop and IOCPEventLoop subclasses.�

The main benefit here is to help clarify that:
1\. the additional methods defined on DescriptorEventLoop and
IOCPEventLoop are not available on all event loop implementations, so
any code using them is necessarily event loop specific
2\. the goal of the transport abstraction is to mask the differences
between these low level platform specific APIs
3\. other event loops are free to use a completely different API
between their low level transports and the event loop


I like the idea of splitting up the big interface, but could you clarify what would go into such subclasses? I.e. isn't the current EventLoop interface supposed to represent an interface all event loops will adhere to?


And sorry if this was discussed before and I'm missing the context, but what kinds of EventLoop implementations are we expecting to see eventually? Is it only a matter of implementing the API per platform (akin to the current tulip.unix_events.UnixEventLoop) or a broader expectation of frameworks like Twisted to plug into the API by providing their own implementation (PEP 3156 mentions this somewhere).

�
Second proposal: better separate the "event loop management", "event
monitoring" and "do things" methods



Do things (and get the result with "yield from"):
\- wrap\_future() # Perhaps "wrap\_executor\_future"?
\- run\_in\_executor()
\- getaddrinfo()
\- getnameinfo()

Low level transport creation:
\- create\_connection()
\- create\_pipe() # Once it exists in the PEP

�
+1 These certainly look somewhat out of place in the generic EventLoop API, but concretely - how do you propose to structure the split?

Eli