From 1fda829833625d7550307d26bfebd96e2354f3a0 Mon Sep 17 00:00:00 2001 From: Guido van Rossum Date: Wed, 12 Dec 2012 18:30:32 -0800 Subject: [PATCH] Added an introduction. --- pep-3156.txt | 75 +++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 68 insertions(+), 7 deletions(-) diff --git a/pep-3156.txt b/pep-3156.txt index 8716be9d7..bd9edf136 100644 --- a/pep-3156.txt +++ b/pep-3156.txt @@ -23,10 +23,70 @@ implementation is in the works under the code name tulip. Introduction ============ -TBD. I'm just committing this now to reserve the PEP number. (I am -using the 3000 range because this proposal is very closely tied to -Python 3, and to emphasise the connection with PEP 3153, which -provides the motivation but falls short of proposing concrete APIs.) +The event loop is the place where most interoperability occurs. It +should be easy for (Python 3.3 ports of) frameworks like Twisted, +Tornado, or ZeroMQ to either adapt the default event loop +implementation to their needs using a lightweight wrapper or proxy, or +to replace the default event loop implementation with an adaptation of +their own event loop implementation. (Some frameworks, like Twisted, +have multiple event loop implementations. This should not be a +problem since these all have the same interface.) + +It should even be possible for two different third-party frameworks to +interoperate, either by sharing the default event loop implementation +(each using its own adapter), or by sharing the event loop +implementation of either framework. In the latter case two levels of +adaptation would occur (from framework A's event loop to the standard +event loop interface, and from there to framework B's event loop). +Which event loop implementation is used should be under control of the +main program (though a default policy for event loop selection is +provided). + +Thus, two separate APIs are defined: + +- getting and setting the current event loop object +- the interface of a conforming event loop and its minimum guarantees + +An event loop implementation may provide additional methods and +guarantees. + +The event loop interface does not depend on yield-from. Rather, it +uses a combination of callbacks, additional interfaces (transports and +protocols), and Futures. The latter are similar to those defined in +PEP 3148, but have a different implementation and are not tied to +threads. In particular, they have no wait() method; the user is +expected to use callbacks. + +For users (like myself) who don't like using callbacks, a scheduler is +provided for writing asynchronous I/O code as coroutines using the PEP +380 yield-from expressions. The scheduler is not pluggable; +pluggability occurs at the event loop level, and the scheduler should +work with any conforming event loop implementation. + +For interoperability between code written using coroutines and other +async frameworks, the scheduler has a Task class that behaves like a +Future. A framework that interoperates at the event loop level can +wait for a Future to complete by adding a callback to the Future. +Likewise, the scheduler offers an operation to suspend a coroutine +until a callback is called. + +Limited interoperability with threads is provided by the event loop +interface; there is an API to submit a function to an executor (see +PEP 3148) which returns a Future that is compatible with the event +loop. + + +Non-goals +========= + +Interoperability with systems like Stackless Python or +greenlets/gevent is not a goal of this PEP. + + +Specification +============= + +TBD. Acknowledgments @@ -37,9 +97,10 @@ tutorial for yield-from, Twisted, Tornado, ZeroMQ, pyftpdlib, tulip (the author's attempts at synthesis of all these), wattle (Steve Dower's counter-proposal), numerous discussions on python-ideas from September through December 2012, a Skype session with Steve Dower and -Dino Viehland, email exchanges with Ben Darnell, and two in-person -meetings with several Twisted developers, including Glyph, Brian -Warner, David Reid, and Duncan McGreggor. +Dino Viehland, email exchanges with Ben Darnell, an audience with +Niels Provos (original author of libevent), and two in-person meetings +with several Twisted developers, including Glyph, Brian Warner, David +Reid, and Duncan McGreggor. Copyright