<div dir="ltr">On Thu, Jan 24, 2013 at 8:23 PM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A pragmatic question popped up: sometimes the protocol would like to<br>
know the name of the socket or its peer, i.e. call getsockname() or<br>
getpeername() on the underlying socket. (I can imagine wanting to log<br>
this, or do some kind of IP address blocking.)<br>
<br>
What should the interface for this look like? I can think of several ways:<br>
<br>
A) An API to return the underlying socket, if there is one. (In the<br>
case of a stack of transports and protocols there may not be one, so<br>
it may return None.) Downside is that it requires the transport to use<br>
sockets -- if it were to use some native Windows API there might not<br>
be a socket object even though there might be an IP connection with<br>
easily-accessible address and peer.<br></blockquote><div><br></div><div style>I feel (A) is the best option as it's the most flexible - underlying transports can have many different special methods. No?</div><div style>

<br></div><div style>Yuval Greenfield</div><div style><br></div></div></div></div>