This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients amaury.forgeotdarc, benjamin.peterson, giampaolo.rodola, pitrou, stutzbach
Date 2010-09-15.19:36:00
SpamBayes Score 4.988483e-05
Marked as misclassified No
Message-id <1284579358.3190.70.camel@localhost.localdomain>
In-reply-to <1284574854.32.0.403686635118.issue9854@psf.upfronthosting.co.za>
Content
> Of course, I should have been more clear.
> What I meant is that there's no such thing as explicit and "native" as
> setblocking() for plain files.

Indeed. It would probably be a nice addition, assuming it is portable
enough.

> > A BlockingIOError is raised if the underlying raw stream is in non 
> > blocking-mode, and has no data available at the moment.
> 
> This is valid for BufferedReader, BufferWriter and BufferIOBase
> classes in various methods while io.RawIOBase.write() and
> io.RawIOBase.read() return None instead. Shouldn't they raise
> BlockingIOError as well? Why do they return None?

Well, that's how it was decided when the new IO lib was designed.
See http://www.python.org/dev/peps/pep-3116/#non-blocking-i-o
(but this says that write() should return 0, while the FileIO
implementation returns None; I'd say that for consistency with read()
and readinto() returning None is the right thing).
History
Date User Action Args
2010-09-15 19:36:02pitrousetrecipients: + pitrou, amaury.forgeotdarc, giampaolo.rodola, benjamin.peterson, stutzbach
2010-09-15 19:36:01pitroulinkissue9854 messages
2010-09-15 19:36:00pitroucreate