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

[Guido van Rossum]

On Fri, Jan 25, 2013 at 3:24 AM, Ronald Oussoren <ronaldoussoren at mac.com>wrote:

>
> On 24 Jan, 2013, at 22:50, Guido van Rossum <guido at python.org> wrote:
>
> > On Thu, Jan 24, 2013 at 12:51 PM, Nick Coghlan <ncoghlan at gmail.com>
> wrote:
> >> On Fri, Jan 25, 2013 at 5:12 AM, Guido van Rossum <guido at python.org>
> wrote:
> >>> On Thu, Jan 24, 2013 at 11:05 AM, Nikolay Kim <fafhrd91 at gmail.com>
> wrote:
> >>>> transport could have dictionary attribute where it can store optional
> information
> >>>> like socket name, peer name or file path, etc.
> >>>
> >>> Aha, that makes some sense. Though maybe it shouldn't be a dict -- it
> >>> may be expensive to populate some values in some cases, so maybe there
> >>> should just be a method transport.get_extra_info('key') which computes
> >>> and returns (and possibly caches) certain values but returns None if
> >>> the info is not supported. E.g. get_extra_info('name'),
> >>> get_extra_info('peer'). This API makes it pretty clear that the caller
> >>> should check the value for None before using it.
> >>
> >> A "get_extra_info" API like that is also amenable to providing an
> >> explicit default for the "key not present" case, and makes it clearer
> >> that the calculations involved may not be cheap.
> >
> > Yeah, the signature could be get_extra_info(key, default=None).
> >
> >> You could even go so
> >> far as to have it return a Future, allowing it to be used for info
> >> that requires network activity.
> >
> > I think that goes too far. It doesn't look like getpeername() goes out
> > to the network -- what other use case did you have in mind? (I suppose
> > it could use a Future for some keys only -- but then the caller would
> > still need to be aware that it could return None instead of a Future,
> > so it would be somewhat awkward to use -- you couldn't write
>
> A transport that tunnels traffic over a SOCKS or SSH tunnel might require
> network access to get the sockname or peername of the proxied connection. I
> don't know enough about either protocol to know for sure, and the
> information could also be fetched during connection setup and then cached.


Sounds good (to fetch it proactively ahead of time, rather than inject a
Future into the API).

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130125/5bd98c00/attachment.html>