[Python-ideas] PEP 3156: Clarifying the different components of the event loop API (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Sun Jan 20 03:34:24 CET 2013
- Previous message: [Python-ideas] chdir context manager
- Next message: [Python-ideas] PEP 3156: Clarifying the different components of the event loop API
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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:
- 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
- the goal of the transport abstraction is to mask the differences between these low level platform specific APIs
- 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
- Previous message: [Python-ideas] chdir context manager
- Next message: [Python-ideas] PEP 3156: Clarifying the different components of the event loop API
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]