[Python-Dev] Draft PEP to make file objects support non-blocking mode.

Paul Moore p.f.moore at gmail.com
Mon Mar 21 14:05:39 CET 2005

On Mon, 21 Mar 2005 17:32:36 +1200, Greg Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> > On 18 March 2005, Donovan Baarda said:
> >>The read method's current behaviour needs to be documented, so its actual
> >>behaviour can be used to differentiate between an empty non-blocking read,
> >>and EOF.  This means recording that IOError(EAGAIN) is raised for an empty
> >>non-blocking read.
> Isn't that unix-specific? The file object is supposed to
> provide a more or less platform-independent interface, I
> thought.

The whole thing is, I believe, highly Unix-specific. I say this
because I am essentially a Windows programmer, and the proposal means
almost nothing to me :-) More seriously, non-blocking IO and
select-type readability checks are VERY different on Windows, and so I
would expect the implementation of this chance to be completely
different as well. The C standard says nothing about non-blocking IO.
While POSIX might, that doesn't apply to Windows.

Oh, and in case it's not obvious, I'm -1 on something "Unix-only"
here. Python file objects are supposed to be cross-platform, in


PS Donovan's sample code seems to be process-related - if so, isn't
that what the new subprocess module was supposed to resolve
(process-related communication in a platform-independent way)? If the
only use case is with subprocesses, then is this change needed at all?

More information about the Python-Dev mailing list