[Python-checkins] peps: Open issues: signals, timeouts. Reminder: factories can be partial funcs.
guido.van.rossum
python-checkins at python.org
Sun Jan 6 00:32:05 CET 2013
http://hg.python.org/peps/rev/cd5c24a3130f
changeset: 4653:cd5c24a3130f
user: Guido van Rossum <guido at google.com>
date: Sat Jan 05 15:32:00 2013 -0800
summary:
Open issues: signals, timeouts. Reminder: factories can be partial funcs.
files:
pep-3156.txt | 28 ++++++++++++++++++++++++++--
1 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/pep-3156.txt b/pep-3156.txt
--- a/pep-3156.txt
+++ b/pep-3156.txt
@@ -269,12 +269,16 @@
Creates a transport and a protocol and ties them together. Returns
a Future whose result on success is a (transport, protocol) pair.
The protocol is created by calling ``protocol_factory()`` without
- arguments. Note that when the Future completes, the protocol's
+ arguments(*). Note that when the Future completes, the protocol's
``connection_made()`` method has not yet been called; that will
happen when the connection handshake is complete. When it is
impossible to connect to the given host and port, the Future will
raise an exception instead.
+ (*) There is no requirement that ``protocol_factory`` is a class.
+ If your protocol class needs to have specific arguments passed to
+ its constructor, you can use ``lambda`` or ``functools.partial()``.
+
Optional keyword arguments:
- ``family``, ``type``, ``proto``, ``flags``: Address familty,
@@ -292,10 +296,12 @@
loop that accepts connections. Returns a Future that completes once
the loop is set up to serve; its return value is None. Each time a
connection is accepted, ``protocol_factory`` is called without
- arguments to create a protocol, a transport is created to represent
+ arguments(*) to create a protocol, a transport is created to represent
the network side of the connection, and the two are tied together by
calling ``protocol.connection_made(transport)``.
+ (*) See footnote above for ``create_transport()``.
+
Optional keyword arguments:
- ``family``, ``type``, ``proto``, ``flags``: Address familty,
@@ -894,6 +900,24 @@
Finally, do we need support for unconnected datagram protocols?
(That would mean wrappers for ``sendto()`` and ``recvfrom()``.)
+- Signal handling. This is pretty UNIX-specific, but sometimes an
+ application needs to intercept signals. It may be handy to have a
+ standard interface for this in the event loop, so everyone doesn't
+ have to reinvent this same wheel (with the same bugs). It's
+ possible that this can be a thin wrapper on top of
+ ``call_soon_threadsafe()`` (assuming its implementation doesn't use
+ locks -- if it does, something different is needed, since a signal
+ handler may run while the thread is already holding a lock).
+
+- We may need APIs to control various timeouts. E.g. we may want to
+ limit the time spent in DNS resolution, connecting, ssl handshake,
+ idle connection, close/shutdown, even per session. Possibly it's
+ sufficient to add ``timeout`` keyword parameters to some methods,
+ and other timeouts can probably be implemented by clever use of
+ ``call_later()`` and ``Task.cancel()``. But it's possible that some
+ operations need default timeouts, and we may want to change the
+ default for a specific operation globally (i.e., per event loop).
+
- 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
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list