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

[Nick Coghlan]

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.

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

Cheers,
Nick.

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