[Python-ideas] PEP 3156: getting the socket or peer name from the transport (original) (raw)
Ronald Oussoren ronaldoussoren at mac.com
Fri Jan 25 12:24:58 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 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.getextrainfo('key') which computes and returns (and possibly caches) certain values but returns None if the info is not supported. E.g. getextrainfo('name'), getextrainfo('peer'). This API makes it pretty clear that the caller should check the value for None before using it. A "getextrainfo" 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 getextrainfo(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.
Ronald
- 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 ]