Remove some vague issues and the wait_one() proposal.

pep-3156.txt

@@ -878,44 +878,10 @@ Open Issues
   given a file descriptor.  Or when the next scheduled call is.  Or
   the list of file descriptors registered with callbacks.
 
-- Should we have ``future.add_callback(callback, *args)``, using the
-  convention from the section "Callback Style" above, or should we
-  stick with the PEP 3148 specification of
-  ``future.add_done_callback(callback)`` which calls
-  ``callback(future)``?  (Glyph suggested using a different method
-  name since add_done_callback() does not guarantee that the callback
-  will be called in the right context.)
-
-- Returning a Future is relatively expensive, and it is quite possible
-  that some types of calls *usually* complete immediately
-  (e.g. writing small amounts of data to a socket).  A trick used by
-  Richard Oudkerk in the tulip project's proactor branch makes calls
-  like recv() either return a regular result or *raise* a Future.  The
-  caller (likely a transport) must then write code like this::
-
-    try:
-        res = ev.sock_recv(sock, 8192)
-    except Future as f:
-        yield from sch.block_future(f)
-        res = f.result()
-
-- Do we need a larger vocabulary of operations for combining
-  coroutines and/or futures?  E.g. in addition to par() we could have
-  a way to run several coroutines sequentially (returning all results
-  or passing the result of one to the next and returning the final
-  result?).  We might also introduce explicit locks (though these will
-  be a bit of a pain to use, as we can't use the ``with lock: block``
-  syntax).  Anyway, I think all of these are easy enough to write
-  using ``Task``.
-
-  Proposal: ``f = yield from wait_one(fs)`` takes a set of Futures and
-  sets f to the first of those that is done.  (Yes, this requires an
-  intermediate Future to wait for.)  You can then write::
-
-    while fs:
-        f = tulip.wait_one(fs)
-        fs.remove(f)
-        <inspect f>        
+- We might introduce explicit locks, though these will be a bit of a
+  pain to use, as we can't use the ``with lock: block`` syntax
+  (because to wait for a lock we'd have to use ``yield from``, which
+  the ``with`` statement can't do).
 
 - Support for datagram protocols, "connected" or otherwise?  Probably
   need more socket I/O methods, e.g. ``sock_sendto()`` and
@@ -923,8 +889,6 @@ Open Issues
   science).  Is it reasonable to map ``write()``, ``writelines()``,
   ``data_received()`` to single datagrams?
 
-- Task or callback priorities?  (I hope not.)
-
 - An EventEmitter in the style of NodeJS?  Or make this a separate
   PEP?  It's easy enough to do in user space, though it may benefit
   from standardization.  (See