<div dir="ltr">Hello.<div><br></div><div>I've read the PEP and some things raise questions in my consciousness. Here they are.</div><div><br></div><div>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:</div>

<div><br></div><div>    sock = socket(...)</div><div style>    # later, e.g. in connect()</div><div>    yield from tulip.get_event_loop().sock_connect(sock, ...)</div><div>    # later, e.g. in read()</div><div>    data = yield from tulip.get_event_loop().sock_recv(sock, ...)</div>

<div><br></div><div style>will look like:</div><div style><br></div><div style>    sock = socket(...)<br>    async_sock = tulip.get_event_loop().wrap_socket(sock)</div><div><div><div>    # later, e.g. in connect()</div><div>

    yield from async_sock.connect(...)</div><div>    # later, e.g. in read()</div><div>    data = yield from async_sock.recv(...)</div><div><br></div><div style>Interface looks cleaner while plain calls (if they ever needed) will be only 5 chars longer.</div>

<div style><br></div><div style>2. Not as great, but still possible to wrap fd in similar way to make interface simpler. Instead of:</div><div style><br></div><div style>    add_reader(fd, callback, *args)<br>    remove_reader(fd)</div>

<div style><br></div><div style>We can do:</div><div style><br></div><div style>    wrap_fd(fd).reader = functools.partial(callback, *args)</div><div style>    wrap_fd(fd).reader = None  # or</div><div style>    del wrap_fd(fd).reader</div>

<div style><br></div><div style>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'.</div>

<div style><br></div><div style>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"?</div>

<div style><br></div><div style>5. I think, protocol and transport methods' names are not easy or understanding enough:</div><div style>- write_eof() does not write anything but closes smth, should be close_writing or smth alike;</div>

<div>- the same way eof_received() should become smth like receive_closed;</div><div style>- pause() and resume() work with reading only, so they should be suffixed (prefixed) with read(ing), like pause_reading(), resume_reading().</div>

<div style><br></div><div style><br></div><div>Kind regards, Yuriy.</div></div>
</div></div>