On Mon, 21 Mar 2005 17:32:36 +1200, Greg Ewing <[EMAIL PROTECTED]> 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 general. Paul. 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? _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
