[Python-checkins] peps: Various small updates.

Sun Dec 16 23:26:54 CET 2012

http://hg.python.org/peps/rev/0d6b37097336
changeset: 4616:0d6b37097336
user: Guido van Rossum <guido at google.com>
date: Sun Dec 16 14:26:48 2012 -0800
summary:
 Various small updates.
files:
 pep-3156.txt | 38 ++++++++++++++++++++++++++++++++------
 1 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/pep-3156.txt b/pep-3156.txt
--- a/pep-3156.txt
+++ b/pep-3156.txt
@@ -120,16 +120,22 @@
 object depending on the current thread, or depending on some other
 notion of context.
 
-To set the current event loop, use ``set_event_loop(eventloop)``,
-where ``eventloop`` is an instance of the ``EventLoop`` class or
+To set the current event loop, use ``set_event_loop(event_loop)``,
+where ``event_loop`` is an instance of the ``EventLoop`` class or
 equivalent. This uses the same notion of context as
 ``get_event_loop()``.
 
-To change the way ``get_event_loop()`` and ``set_event_loop()`` work
+For the benefit of unit tests and other special cases there's a third
+policy function: ``init_event_loop()``, which creates a new EventLoop
+instance and calls ``set_event_loop()`` with it. TBD: Maybe we should
+have a ``create_default_event_loop_instance()`` function instead?
+
+To change the way the above three functions work
 (including their notion of context), call
 ``set_event_loop_policy(policy)``, where ``policy`` is an event loop
 policy object. The policy object can be any object that has methods
-``get_event_loop()`` and ``set_event_loop(eventloop)`` behaving like
+``get_event_loop()``, ``set_event_loop(event_loop)``
+and ``init_event_loop()`` behaving like
 the functions described above. The default event loop policy is an
 instance of the class ``DefaultEventLoopPolicy``. The current event loop
 policy object can be retrieved by calling ``get_event_loop_policy()``.
@@ -219,7 +225,7 @@
 ``run_in_executor()``, but other implementations may choose to
 implement their own DNS lookup.
 
-- ``getnameinfo(sockaddr, flags)``. Similar to
+- ``getnameinfo(sockaddr, flags=0)``. Similar to
 ``socket.getnameinfo()`` but returns a Future. The Future's result
 on success will be a tuple ``(host, port)``. Same implementation
 remarks as for ``getaddrinfo()``.
@@ -436,7 +442,9 @@
 and ignoring the convention from the section "Callback Style" below)
 is always called with a single argument, the Future object.
 
-The internal methods defined in PEP 3148 are not supported.
+The internal methods defined in PEP 3148 are not supported. (TBD:
+Maybe we do need to support these, in order to make it easy to write
+user code that returns a Future?)
 
 A ``tulip.Future`` object is not acceptable to the ``wait()`` and
 ``as_completed()`` functions in the ``concurrent.futures`` package.
@@ -446,6 +454,11 @@
 ``__iter__()`` interface on the Future. See the section "Coroutines
 and the Scheduler" below.
 
+When a Future is garbage-collected, if it has an associated exception
+but neither ``result()`` nor ``exception()`` nor ``__iter__()`` has
+ever been called (or the latter hasn't raised the exception yet --
+details TBD), the exception should be logged. TBD: At what level?
+
 In the future (pun intended) we may unify ``tulip.Future`` and
 ``concurrent.futures.Future``, e.g. by adding an ``__iter__()`` method
 to the latter that works with ``yield from``. To prevent accidentally
@@ -737,6 +750,17 @@
 public interface of the event loop, so it will work with third-party
 event loop implementations, too.
 
+Sleeping
+--------
+
+TBD: ``yield sleep(seconds)``. Can use ``sleep(0)`` to suspend to
+poll for I/O.
+
+Wait for First
+--------------
+
+TBD: Need an interface to wait for the first of a collection of Futures.
+
 Coroutines and Protocols
 ------------------------
 
@@ -762,6 +786,8 @@
 any ``yield from`` operation). We need to spell out which exception
 is raised.
 
+Also TBD: timeouts.
+
 
 Open Issues
 ===========
-- 
Repository URL: http://hg.python.org/peps
