[Python-ideas] PEP 3156 feedback

[Andrew Svetlov]

About protocols: I think eventloop should support UDP datagrams as
well as operations with file descriptors which are not sockets at all.
I mean timerfd_create and inotify as examples.

On Wed, Dec 19, 2012 at 12:39 AM, Guido van Rossum <guido at python.org> wrote:
> On Tue, Dec 18, 2012 at 12:44 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> On Tue, 18 Dec 2012 12:41:04 -0800
>> Guido van Rossum <guido at python.org> wrote:
>>> > So "if error is None: return" is all you have to do to filter out the
>>> > boring case.
>>>
>>> But a clean close from the other end (as opposed to an unexpected
>>> disconnect e.g. due to a sudden network partition) also passes None. I
>>> guess this is okay because in that case eof_received() is first
>>> called. So I guess the PEP is already okay here. :-)
>>
>> Only if the protocol supports EOF, though? Or do you "emulate" by
>> calling eof_received() in any case?
>
> EOF is part of TCP (although I'm sure it has a different name at the
> protocol level). The sender can force it by using shutdown(SHUT_WR)
> (== write_eof() in Tulip/PEP 3156) or just by closing the socket (if
> they don't expect a response). The low-level reader detects this by
> recv() returning an empty string. Of course, if the other end closed
> both halves and you try to write before reading, send() may raise an
> exception and then you'll not get the EOF. And then again, send() may
> not raise an exception, it all depends on where stuff gets buffered.
> But arguably you get what you ask for in that case.
>
> I plan to call eof_received(), once, if and only if recv() returns an
> empty byte string.
>
> (The PEP says that eof_received() should call close() by default, but
> I don't actually think that's correct -- it also is hard to put in the
> abstract Protocol class unless a specific instance variable holding
> the transport is made part of the spec, which I am hesitant to do. I
> don't think that ignoring it by default is actually a problem.)
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas



-- 
Thanks,
Andrew Svetlov