[Python-ideas] [Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted (original) (raw)
Guido van Rossum guido at python.org
Wed Jan 9 07:02:58 CET 2013
- Previous message: [Python-ideas] [Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted
- Next message: [Python-ideas] [Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Jan 8, 2013 at 9:26 PM, Yuriy Taraday <yorik.sar at gmail.com> wrote:
On Wed, Jan 9, 2013 at 9:14 AM, Guido van Rossum <guido at python.org> wrote: On Tue, Jan 8, 2013 at 9:02 PM, Yuriy Taraday <yorik.sar at gmail.com> wrote: > 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. But in theory every sock call is independent and returns Future bound to current event loop.
It is bound to the event loop whose sock_() method you called.
So if one change event loop with active transport, nothing bad should happen. Or I'm missing something.
Changing event loops in the middle of event processing is not a common (or even useful) pattern. You start the event loop and then leave it alone.
> 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. When I see (in autocompletion, for example) or remember name like "running", it triggers thought that it's a field. When I remember smth like isrunning, it definitely associates with method.
That must pretty specific to your personal experience.
> 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. Yes, not a big deal.
>> > 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 :-). >> > 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 halfclose() 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. Yes, 'write' part is good, I should mention it. I meant to say that I won't need to explain that there were days when we had to handle a special marker at the end of file.
But even today you have to mark the end somehow, to distinguish it from "not done yet, more could be coming". The equivalent is typing ^D into a UNIX terminal (or ^Z on Windows).
-- --Guido van Rossum (python.org/~guido)
- Previous message: [Python-ideas] [Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted
- Next message: [Python-ideas] [Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]