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

Le dimanche 27 janvier 2013 à 14:12 +0200, Yuval Greenfield a écrit :
What I meant is that the HTTP protocol needs to know that it is running over a secure transport, and it needs to fetch the server certificate from that transport (or, alternatively, it needs to have one of its callbacks called by the transport when the certificate is known). That's not entirely transport-agnostic. Regards Antoine.

On Sun, Jan 27, 2013 at 4:16 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Yeah, it sounds like in the end having access to the socket itself (if there is one) may be necessary. I suppose there are a number of different ways to handle that specific use case, but it seems clear that we can't anticipate all use cases. I'd rather have a simpler abstraction with an escape hatch than attempting to codify more use cases into the abstraction. We can always iterate on the design after Python 3.4, if there's a useful generalization we didn't anticipate. -- --Guido van Rossum (python.org/~guido)

On Jan 27, 2013, at 8:28 AM, Guido van Rossum <guido@python.org> wrote:
What about giving the protocol an environ info object that should have all information it needs already, which could (and probably should) include things like the SSL certificate information, and would probably also be where additional info that happened to be looked up, like host name details, was stored and accessed. Assuming the transports, etc., can define all the state information a protocol needs, can operate without hardware dependencies; in case that doesn't happen, though, the state dict will also have references to the socket, so the protocol could get to directly if needed.

On Mon, Jan 28, 2013 at 12:57 AM, Shane Green <shane@umbrellacode.com> wrote:
Hm. I'm not keen on precomputing all of that, since most protocols won't need it, and the cost add up. This is not WSGI. The protocol has the transport object and can ask it specific questions -- if through a general API, like get_extra_info(key, [default]). -- --Guido van Rossum (python.org/~guido)

Right. I was thinking about it from too high of a level, I think, and focused too much on a single example, HTTPS. To clarify a couple things, though, I actually didn't mean for transports to populate the state with superfluous information or things they didn't already know. Again, based on the single example I was considering, i was thinking they could intelligently populate it with state they know will be needed, and already have. Like the HTTPS server spawning a new HTTPS transport channel knows the channel will need its SSL information, and the transport can add it's own socket connection to the state in case the protocol needs it. I had also thought the state might somehow end up participating in get_extra_info(), so the expensive information returned was stored there; more importantly, though, I didn't mean for any such calls to be made preemptively in an attempt to populate state just in case a protocol did need it. HTTPS is a single, atypical example that's too high-level…and something similar to WSGI seemed like a reasonable approach ;-) Shane Green www.umbrellacode.com 408-692-4666 | shane@umbrellacode.com On Jan 28, 2013, at 7:45 AM, Guido van Rossum <guido@python.org> wrote:

On Mon, Jan 28, 2013 at 5:45 PM, Guido van Rossum <guido@python.org> wrote:
I forgot to ask before, but why is get_extra_info better than normal attributes and methods? val = transport.get_extra_info(key, None) if val is None: pass # vs if hasattr(transport, key): val = transport.key else: pass Yuval

On Thu, Jan 31, 2013 at 12:52 AM, Yuval Greenfield <ubershmekel@gmail.com> wrote:
val = getattr(transport, key)
You probably meant val = getattr(transport, "key", None) Your original example also forgot the quotes around "key" in the hasattr() call.) The number of attempts needed to get your example right tells me this is not a good proposal. :-) -- --Guido van Rossum (python.org/~guido)

On Thu, Jan 31, 2013 at 12:51 AM, Yuval Greenfield <ubershmekel@gmail.com> wrote:
hasattr() smells bad. It also has namespace issues (hasattr(transport, "write") returns true) and if people forget to use it (perhaps because the transport they normally use always has a certain attribute) their code is brittle. Defining a new API with a string key signals clearly that the value may or may not exist, and reminds people to test the result for None. (Of course they can forget that too. But it still feels different to me.) -- --Guido van Rossum (python.org/~guido)

On Fri, Feb 1, 2013 at 3:58 AM, Guido van Rossum <guido@python.org> wrote:
I understand. It's a good solution for clearly separating the standard transport api from the extra-and-specific api. We want to make it obvious when a protocol is breaking the transport abstraction - to promote playing nicely with different transports.

On Sun, Jan 27, 2013 at 4:16 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Yeah, it sounds like in the end having access to the socket itself (if there is one) may be necessary. I suppose there are a number of different ways to handle that specific use case, but it seems clear that we can't anticipate all use cases. I'd rather have a simpler abstraction with an escape hatch than attempting to codify more use cases into the abstraction. We can always iterate on the design after Python 3.4, if there's a useful generalization we didn't anticipate. -- --Guido van Rossum (python.org/~guido)

On Jan 27, 2013, at 8:28 AM, Guido van Rossum <guido@python.org> wrote:
What about giving the protocol an environ info object that should have all information it needs already, which could (and probably should) include things like the SSL certificate information, and would probably also be where additional info that happened to be looked up, like host name details, was stored and accessed. Assuming the transports, etc., can define all the state information a protocol needs, can operate without hardware dependencies; in case that doesn't happen, though, the state dict will also have references to the socket, so the protocol could get to directly if needed.

On Mon, Jan 28, 2013 at 12:57 AM, Shane Green <shane@umbrellacode.com> wrote:
Hm. I'm not keen on precomputing all of that, since most protocols won't need it, and the cost add up. This is not WSGI. The protocol has the transport object and can ask it specific questions -- if through a general API, like get_extra_info(key, [default]). -- --Guido van Rossum (python.org/~guido)

Right. I was thinking about it from too high of a level, I think, and focused too much on a single example, HTTPS. To clarify a couple things, though, I actually didn't mean for transports to populate the state with superfluous information or things they didn't already know. Again, based on the single example I was considering, i was thinking they could intelligently populate it with state they know will be needed, and already have. Like the HTTPS server spawning a new HTTPS transport channel knows the channel will need its SSL information, and the transport can add it's own socket connection to the state in case the protocol needs it. I had also thought the state might somehow end up participating in get_extra_info(), so the expensive information returned was stored there; more importantly, though, I didn't mean for any such calls to be made preemptively in an attempt to populate state just in case a protocol did need it. HTTPS is a single, atypical example that's too high-level…and something similar to WSGI seemed like a reasonable approach ;-) Shane Green www.umbrellacode.com 408-692-4666 | shane@umbrellacode.com On Jan 28, 2013, at 7:45 AM, Guido van Rossum <guido@python.org> wrote:

On Mon, Jan 28, 2013 at 5:45 PM, Guido van Rossum <guido@python.org> wrote:
I forgot to ask before, but why is get_extra_info better than normal attributes and methods? val = transport.get_extra_info(key, None) if val is None: pass # vs if hasattr(transport, key): val = transport.key else: pass Yuval

On Thu, Jan 31, 2013 at 12:52 AM, Yuval Greenfield <ubershmekel@gmail.com> wrote:
val = getattr(transport, key)
You probably meant val = getattr(transport, "key", None) Your original example also forgot the quotes around "key" in the hasattr() call.) The number of attempts needed to get your example right tells me this is not a good proposal. :-) -- --Guido van Rossum (python.org/~guido)

On Thu, Jan 31, 2013 at 12:51 AM, Yuval Greenfield <ubershmekel@gmail.com> wrote:
hasattr() smells bad. It also has namespace issues (hasattr(transport, "write") returns true) and if people forget to use it (perhaps because the transport they normally use always has a certain attribute) their code is brittle. Defining a new API with a string key signals clearly that the value may or may not exist, and reminds people to test the result for None. (Of course they can forget that too. But it still feels different to me.) -- --Guido van Rossum (python.org/~guido)

On Fri, Feb 1, 2013 at 3:58 AM, Guido van Rossum <guido@python.org> wrote:
I understand. It's a good solution for clearly separating the standard transport api from the extra-and-specific api. We want to make it obvious when a protocol is breaking the transport abstraction - to promote playing nicely with different transports.
participants (4)
-
Antoine Pitrou
-
Guido van Rossum
-
Shane Green
-
Yuval Greenfield