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

[Glyph]

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

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

Aah.  Yes, I think you're right about that being a bug.  There are probably some docs in Twisted that could be improved to explain that this ordering is part of our analogous interface's contract...

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

I wasn't clear if you were arguing against it; I just wanted to make it clear :).

-glyph