[Python-ideas] PEP 3156: getting the socket or peer name from the transport (original) (raw)
Guido van Rossum guido at python.org
Thu Jan 24 19:44:48 CET 2013
- Previous message: [Python-ideas] PEP 3156: getting the socket or peer name from the transport
- Next message: [Python-ideas] PEP 3156: getting the socket or peer name from the transport
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, Jan 24, 2013 at 10:41 AM, Nikolay Kim <fafhrd91 at gmail.com> wrote:
On Jan 24, 2013, at 10:23 AM, Guido van Rossum <guido at python.org> wrote:
C) Similar to (A) or (B), but putting the API in an abstract subclass of Transport (e.g. SocketTransport) so that a transport that doesn't have this doesn't need to implement dummy methods returning None -- it is now the protocol's responsibility to check for isinstance(transport, SocketTransport) before calling the method. I'm not so keen on this, Twisted has shown (IMO) that a deep hierarchy of interfaces or ABCs does not necessarily provide clarity.
SocketTransport could be abstract just like Transport class, just for description purpose.
Yes, but I'm arguing against this. :-)
Another question, should we expect ability to use protocols on top of different transports (i.e. HTTPProtocol and UnixSubprocessTransport) ?
Yes, it should be possible, for example the subprocess might implement some kind of custom tunnel. If in this case there's no way to get the socket or peer name, or if the names aren't very useful, that's okay.
-- --Guido van Rossum (python.org/~guido)
- Previous message: [Python-ideas] PEP 3156: getting the socket or peer name from the transport
- Next message: [Python-ideas] PEP 3156: getting the socket or peer name from the transport
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]