[Python-ideas] PEP 3156: Clarifying the different components of the event loop API

Sun Jan 20 03:34:24 CET 2013

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
Second proposal: better separate the "event loop management", "event
monitoring" and "do things" methods
I don't have a clear idea of how to do this yet (beyond restructuring
the documentation of the event loop API in the PEP), but I can at
least describe the split I see (along with a few name changes that may
be worth considering).
Event loop management:
- run_once()
- run() # Perhaps "run_until_idle()"?
- run_forever() # Perhaps "run_until_stop()"?
- run_until_complete()
- stop()
- close()
- set_default_executor()
Event monitoring:
- add_signal_handler()
- remove_signal_handler()
- start_serving() # (The "stop serving" API is TBD in the PEP)
Do things (fire and forget):
- call_soon()
- call_soon_threadsafe()
- call_later()
- call_repeatedly()
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
Cheers,
Nick.
P.S. Off-topic for the thread, but I think the existence of run_once
vs run (or run_until_idle) validates the decision to stick with only
running one generation of ready callbacks per iteration. I forgot
about it when we were discussing that question.
-- 
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia