[Python-3000] Non-blocking I/O? (Draft PEP for New IO system)

Greg Ewing greg.ewing at canterbury.ac.nz
Wed Mar 7 09:56:10 CET 2007


Guido van Rossum wrote:
> ValueError is
> typically a bug in the immediate code containing the call.

Not necessarily, because the value may have been
stored somewhere for a while before being used.

> IOError is
> something that could happen even to valid calls (e.g. when a library
> is passed a stream that happens to have been put in nonblocking mode;

But the calling code has made a mistake by passing
such a stream to the library in the first place.

> if the library has a recovery for other I/O errors like disk full or
> broken connections, the recovery should be applied in this case, too).

I don't see how. For something like "Disk full", the
library can report it to the application, and the
application can notify the user and tell him to make
more room somehow. But how can the application recover
from trying to use a non-blocking socket inappropriately?
It's not the user's fault, and there's nothing the user
can to do fix it.

I'd much rather the whole EnvironmentError subtree were
reserved for external things that the user can do something
about. That way the application can easily sort out what
should be reported as a user error, and what should be
reported as a program bug.

I realise this isn't quite true at the moment, because
things like passing invalid parameters to a system call
will probably produce an IOError or OSError. But there's
no sense in muddying things any further if it can be
easily avoided.

--
Greg


More information about the Python-3000 mailing list