[Python-Dev] Comments of the PEP 3151

[Antoine Pitrou]

On Mon, 25 Jul 2011 15:28:47 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> > If we add EINTR, I don't know if it's better to add it to
> > BlockingIOError or to create a new exception (InterruptError?).
> 
> InterruptedError seems like a reasonable candidate for addition to me
> - catch and retry in that case is something developers are likely to
> want to do.

Ok, let's call it InterruptError then. InterruptedError sounds like the
error was interrupted ;)

> Perhaps EPIPE should map to FileDescriptorError along with EBADF, with
> different messages based on the exact error code? Potentially renamed
> to DescriptorStateError?

I'd rather have a separate BrokenPipeError for EPIPE.
EBADF and EPIPE are really quite different; EPIPE indicates that the
other end of the pipe closed it, while EBADF generally points to a
programming error (you are giving an invalid file descriptor to a
system routine).

> To be honest though, what's the use case for *catching*
> FileDescriptorError without catching IOError in general? Perhaps this
> one should be dropped entirely, to be handled by broadly catching
> IOError?

Good point indeed.

> > I'm in favor of adding a note in the documentation of all legacy
> > exceptions to advice to use IOError or specific exceptions instead. I
> > suppose that these notes will have to indicate a Python version.
> 
> +1 for grandfathering in the old exception names, but documenting the
> recommended alternatives as of 3.3.

Ok.

> It may also be reasonable to return a new DeviceNotAvailableError for
> ENODEV and EBUSY (as a new FileSystemError subclass).

EBUSY is really quite different from these other errors. It is
triggered by runtime protections in the OS (can't destroy some object
that is in use, see for example in pthread_cond_destroy:
http://pubs.opengroup.org/onlinepubs/009604499/functions/pthread_cond_destroy.html),
rather than indication some misassumption about the filesystem layout.

As for ENODEV, I'll have to take a look.

> There may be some error codes that we choose to map to these generic
> errors, even if we don't give them their own exception types at this
> point (e.g. ECONSHUTDOWN could map directly to ConnectionError).

Good point as well.

Regards

Antoine.