[Python-ideas] Tulip / PEP 3156 (original) (raw)
[Python-ideas] Tulip / PEP 3156 - subprocess events
Greg Ewing greg.ewing at canterbury.ac.nz
Sat Jan 19 01:42:20 CET 2013
- Previous message: [Python-ideas] Tulip / PEP 3156 - subprocess events
- Next message: [Python-ideas] Tulip / PEP 3156 - subprocess events
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
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.
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.
-- Greg
- Previous message: [Python-ideas] Tulip / PEP 3156 - subprocess events
- Next message: [Python-ideas] Tulip / PEP 3156 - subprocess events
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]