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 sbt
Recipients petri.lehtinen, pitrou, sbt
Date 2011-11-03.15:14:18
SpamBayes Score 1.082302e-08
Marked as misclassified No
Message-id <1320333259.15.0.891356833463.issue13322@psf.upfronthosting.co.za>
In-reply-to
Content
Wierdly, it looks like BlockingIO is not raised anywhere in the code for the C implementation of io.

Even more wierdly, in the Python implementation of io, BlockingIOError is only ever raised by except clauses which have already caught BlockingIOError.  So, of course, these clauses are dead code.

The only code in CPython which can ever succesfully raise BlockingIOError is MockNonBlockWriterIO.write() in test/test_io.py.

I don't know what the correct behaviour is for flush() and close() if you get EAGAIN.  I think flush() should raise an error rather than blocking, and that close() should delegate to self.raw.close() before raising the error.

The docs say that read(), readinto() and write() can raise BlockingIOError.  But what should readall() and readline() do?  Should we just try to emulate whatever Python's old libc IO system did (with BlockingIOError replacing IOError(EAGAIN))?
History
Date User Action Args
2011-11-03 15:14:19sbtsetrecipients: + sbt, pitrou, petri.lehtinen
2011-11-03 15:14:19sbtsetmessageid: <1320333259.15.0.891356833463.issue13322@psf.upfronthosting.co.za>
2011-11-03 15:14:18sbtlinkissue13322 messages
2011-11-03 15:14:18sbtcreate