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

[Guido van Rossum]

On Fri, Jan 18, 2013 at 4:42 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Guido van Rossum wrote:
>> I like everyone using the same names for these
>> callback methods, so that a reader (who is familiar with the
>> transport/protocol API) can instantly know what kind of callback it is
>> and what its arguments are.

> You don't seem to follow this philosophy anywhere else in
> the PEP, though. In all the other places a callback is
> specified, you get to pass in an arbitrary function.
> The PEP offers no rationale as to why transports should
> be the odd one out.

Well, yes, it *is* the odd one (or two, counting start_serving()) out.
That's because it is the high-level API.

>> You can write an alternative framework using coroutines and callbacks,
>> bypassing transports and protocols. (You'll still need Futures.)
>> However you'd be missing the interoperability offered by the
>> protocol/transport abstractions: in an IOCP world you'd have to
>> interact with the event loop's callbacks differently than in a
>> select/poll/etc. world.

> I was hoping there would be a slightly higher-level layer,
> that provides a coroutine interface but hides the platform
> differences.

Hm, Transports+Protocols *is* the higher level layer.

> What would you think of the idea of making the Transport
> objects themselves fill both roles, by having read_async
> and write_async methods? They wouldn't have to do any
> buffering, I'd be happy to wrap another object around it
> if I wanted that.

You could code that up very simply using sock_recv() and
sock_sendall(). But everyone who's thought about performance of
select/poll/etc., seems to think that that is not a good model because
it will cause many extra calls to add/remove reader/writer.

-- 
--Guido van Rossum (python.org/~guido)