[Python-ideas] PEP 3156: getting the socket or peer name from the transport

[Guido van Rossum]

On Thu, Jan 24, 2013 at 10:45 AM, Yuval Greenfield
<ubershmekel at gmail.com> wrote:
> On Thu, Jan 24, 2013 at 8:23 PM, Guido van Rossum <guido at python.org> wrote:
>>
>> A pragmatic question popped up: sometimes the protocol would like to
>> know the name of the socket or its peer, i.e. call getsockname() or
>> getpeername() on the underlying socket. (I can imagine wanting to log
>> this, or do some kind of IP address blocking.)
>>
>> What should the interface for this look like? I can think of several ways:
>>
>> A) An API to return the underlying socket, if there is one. (In the
>> case of a stack of transports and protocols there may not be one, so
>> it may return None.) Downside is that it requires the transport to use
>> sockets -- if it were to use some native Windows API there might not
>> be a socket object even though there might be an IP connection with
>> easily-accessible address and peer.
>
>
> I feel (A) is the best option as it's the most flexible - underlying
> transports can have many different special methods. No?

The whole idea of defining a transport API is that the protocol
shouldn't care about what type of transport it is being used with. The
example of using an http client protocol with a subprocess transport
that invokes some kind of tunneling process might clarify this. So I
would like the transport API to be both small and fixed, rather than
having different transports have different extensions to the standard
transport API.

What other things might you want to do with the socket besides calling
getpeername() or getsockname()? Would that be reasonable to expect
from a protocol written to be independent of the specific transport
type?

-- 
--Guido van Rossum (python.org/~guido)