[Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted

[Guido van Rossum]

On Tue, Jan 8, 2013 at 9:02 PM, Yuriy Taraday <yorik.sar at gmail.com> wrote:
> On Wed, Jan 9, 2013 at 8:31 AM, Guido van Rossum <guido at python.org> wrote:
>> On Tue, Jan 8, 2013 at 5:14 PM, Yuriy Taraday <yorik.sar at gmail.com> wrote:
>> > 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 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.
>>
>> Ditto.
>
>
> Ok, I see.
> Should transports be bound to event loop on creation? I wonder, what would
> happen if someone changes current event loop between these calls.

Yes, this is what the transport implementation does.

>> > 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.
>>
>
> I understand why it should be a method, but still if it's a getter, it
> should have either get_ or is_ prefix.

Why? That's not a universal coding standard. The names seem clear enough to me.

> Are there any way to change this with 'Final' PEP?

No, the concurrent.futures package has been released (I forget if it
was Python 3.2 or 3.3) and we're bound to backwards compatibility.
Also I really don't think it's a big deal at all.

>> > 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:
>> > - write_eof() does not write anything but closes smth, should be
>> > close_writing or smth alike;
>> > - the same way eof_received() should become smth like receive_closed;
>>
>> 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 :-).
>>
> I never saw a computer working with a tape, but it's clear to me what does
> they do.
> I've just imagined the amount of words I'll have to say to students about
> EOFs instead of simple "it closes our end of one half of a socket".

But which half? A socket is two independent streams, one in each
direction. Twisted uses half_close() for this concept but unless you
already know what this is for you are left wondering which half. Which
is why I like using 'write' in the name.

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