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

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

Guido van Rossum guido at python.org
Sat Jan 19 02:16:54 CET 2013

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 readasync and writeasync 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)

More information about the Python-ideas mailing list