[Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted (original) (raw)

Guido van Rossum guido at python.org
Wed Jan 9 05:31:58 CET 2013

On Tue, Jan 8, 2013 at 5:14 PM, Yuriy Taraday <yorik.sar at gmail.com> wrote:

I've read the PEP and some things raise questions in my consciousness. Here they are.

Thanks!

1. Series of sock methods can be organized into a wrapper around sock object. This wrappers can then be saved and used later in async-aware code. This way code like:

sock = socket(...) # later, e.g. in connect() yield from tulip.geteventloop().sockconnect(sock, ...) # later, e.g. in read() data = yield from tulip.geteventloop().sockrecv(sock, ...) will look like: sock = socket(...) asyncsock = tulip.geteventloop().wrapsocket(sock) # later, e.g. in connect() yield from asyncsock.connect(...) # later, e.g. in read() data = yield from asyncsock.recv(...) Interface looks cleaner while plain calls (if they ever needed) will be only 5 chars longer.

This is a semi-internal API that is mostly useful to Transport implementers, and there won't be many of those. So I prefer the API that has the fewest classes.

2. Not as great, but still possible to wrap fd in similar way to make interface simpler. Instead of:

addreader(fd, callback, *args) removereader(fd) We can do: wrapfd(fd).reader = functools.partial(callback, *args) wrapfd(fd).reader = None # or del wrapfd(fd).reader

Ditto.

3. Why not use properties (or fields) instead of methods for cancelled, running and done in Future class? I think, it'll be easier to use since I expect such attributes to be accessed as properties. I see it as some javaism since in Java Future have getters for this fields but they are prefixed with 'is'.

Too late, this is how PEP 3148 defined it. It was indeed inspired by Java Futures. However I would defend using methods here, since these are not all that cheap -- they have to acquire and release a lock.

4. Why separate exception() from result() for Future class? It does the same as result() but with different interface (return instead of raise). Doesn't this violate the rule "There should be one obvious way to do it"?

Because it is quite awkward to check for an exception if you have to catch it (4 lines instead of 1).

5. I think, protocol and transport methods' names are not easy or understanding enough: - writeeof() does not write anything but closes smth, should be closewriting or smth alike; - the same way eofreceived() should become smth like receiveclosed;

I am indeed struggling a bit with these names, but "writing an EOF" is actually how I think of this (maybe I am dating myself to the time of mag tapes though :-).

- pause() and resume() work with reading only, so they should be suffixed (prefixed) with read(ing), like pausereading(), resumereading().

Agreed.

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

More information about the Python-Dev mailing list