[Python-ideas] Tulip / PEP 3156 - subprocess events

[Glyph]

On Jan 19, 2013, at 10:13 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> When the two are separated without a clear definition of what else can
> happen in between, *every other method on the protocol* needs to cope
> with the fact that other calls to protocol methods may happen in
> between the call to __init__ and the call to connection_made - you
> simply can't write a protocol without dealing with that problem.


Nope. You only have to deal with the methods that the transport will call on the protocol in that state, since nothing else has a reference to it yet.

Except the transport won't call them in that state, so... still nope.

Again: there's enormous corpus of Twisted code out there that is written this way, you can go look at that code to see how it deals with the problem you've imagined, which is to say: it doesn't.  It doesn't need to.

Now, if you make the change you're proposing, and tie together the protocol's construction with the transport's construction, so that you end up with protocol(transport(...)), this means that the protocol will immediately begin interacting with the transport in this vague, undefined, not quite connected state, because, since the protocol didn't even exist at the time of the transport's construction, the transport can't possibly have a reference to a protocol yet.  And the side of the protocol that issues a greeting will necessarily need to do transport.write(), which may want to trigger a notification to the protocol of some kind (flow control?), and where will that notification go?  It needs to be solved less often, but it's a much trickier problem to solve.

There are also some potential edge-cases where the existing Twisted-style design might be nicer, like delivering explicit TLS handshake notifications to protocols which support them in the vague state between protocol construction and connection_made, but seeing as how I still haven't gotten around to implementing that properly in Twisted, I imagine it will be another 10 years before Tulip is practically concerned with it :).

Finally, I should say that Guido's point about the transport constructor being private is actually somewhat important.  We've been saying 'transport(...)' thus far, but in fact it's more like 'SocketTransport(loop, socket)'.  Or perhaps in the case of a pipe, 'PipeTransport(loop, readfd, writefd)'.  In the case of an actual outbound TCP connection with name resolution, it's 'yield from make_outgoing_tcp_transport(loop, hostname, port)'.  Making these all methods that hide the details and timing of the transport's construction is a definite plus.

-glyph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130119/7b87c565/attachment.html>