[Python-ideas] PEP 3156: getting the socket or peer name from the transport (original) (raw)
Nikolay Kim fafhrd91 at gmail.com
Thu Jan 24 19:41:51 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 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.
Another question, should we expect ability to use protocols on top of different transports (i.e. HTTPProtocol and UnixSubprocessTransport) ?
- 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 ]