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

[Guido van Rossum]

(I'm out of time to respond at length, but I think you have a good
point here and I expect I will heed it. It may be a while before I
have time for another sprint with the PEP and Tulip though.)

On Sat, Jan 19, 2013 at 6:34 PM, Nick Coghlan <ncoghlan at 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
>
> 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
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas



-- 
--Guido van Rossum (python.org/~guido)