homepage

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

AltStyle によって変換されたページ (->オリジナル) /