[Python-ideas] PEP 3156 feedback

[Guido van Rossum]

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)