[Python-ideas] Tulip / PEP 3156 (original) (raw)

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

Nick Coghlan ncoghlan at gmail.com
Sun Jan 20 08🔞33 CET 2013

On Sun, Jan 20, 2013 at 4:51 PM, Glyph <glyph at twistedmatrix.com> wrote:

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 connectionmade - 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.

Yes, after Guido explained how tulip was currently handling this, I realised that the problem was mostly one of documentation. However, I think there is one key bug in the current implementation, which is that create_connection is returning before the call to "connection_made" is completed, thus exposing the protocol in an incompletely initialised state.

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 makeoutgoingtcptransport(loop, hostname, port)'. Making these all methods that hide the details and timing of the transport's construction is a definite plus.

Yes, I didn't have a problem with that part - it was just the lack of clear explanation of the different roles of the protocol constructor and the connection_made callback that I found problematic.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-ideas mailing list