Move wrap_future() out of EventLoop. Document local_addr.

pep-3156.txt

@@ -406,10 +406,6 @@ Thread interaction
   signal-safe; if you want to handle signals, use
   ``add_signal_handler()`` described below.
 
-- ``wrap_future(future)``.  This takes a PEP 3148 Future (i.e., an
-  instance of ``concurrent.futures.Future``) and returns a Future
-  compatible with the event loop (i.e., a ``tulip.Future`` instance).
-
 - ``run_in_executor(executor, callback, *args)``.  Arrange to call
   ``callback(*args)`` in an executor (see PEP 3148).  Returns a Future
   whose result on success is the return value of that call.  This is
@@ -424,6 +420,9 @@ Thread interaction
   ``Executor`` instance or ``None``, in order to reset the default
   executor.
 
+See also the ``wrap_future()`` function described in the section about
+Futures.
+
 Internet name lookups
 '''''''''''''''''''''
 
@@ -518,6 +517,12 @@ use a different transport and protocol interface.
     arguments.  If this is given, host and port must be omitted;
     otherwise, host and port are required.
 
+  - ``local_addr``: If given, a ``(host, port)`` tuple used to bind
+    the socket to locally.  This is rarely needed but on multi-homed
+    servers you occasionally need to force a connection to come from a
+    specific address.  This is how you would do that.  The host and
+    port are looked up using ``getaddrinfo()``.
+
 - ``start_serving(protocol_factory, host, port, **kwds)``.  Enters a
   serving loop that accepts connections.  This is a Task that
   completes once the serving loop is set up to serve.  The return
@@ -892,12 +897,19 @@ 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
 blocking the event loop by calling e.g. ``result()`` on a Future
-that's not don yet, the blocking operation may detect that an event
+that's not done yet, the blocking operation may detect that an event
 loop is active in the current thread and raise an exception instead.
 However the current PEP strives to have no dependencies beyond Python
 3.3, so changes to ``concurrent.futures.Future`` are off the table for
 now.
 
+There is one public function related to Futures.  It is:
+
+- ``wrap_future(future)``.  This takes a PEP 3148 Future (i.e., an
+  instance of ``concurrent.futures.Future``) and returns a Future
+  compatible with the event loop (i.e., a ``tulip.Future`` instance).
+
+
 Transports
 ----------