[Python-Dev] Comments of the PEP 3151

[Antoine Pitrou]

Hello,

> By the way, is it faster to not handle and than re-raise unwanted
> exceptions?

You mean "is it faster to not handle than re-raise unwanted
exceptions?". It probably is, yes.

> I don't understand how Antoine decided which errno should have an
> exception or not.

Mostly experience with the stdlib combined with intuition. The list is
not cast in stone.

> If we add EINTR, I don't know if it's better to add it to
> BlockingIOError or to create a new exception (InterruptError?).

EINTR is not related to non-blocking I/O, so it shouldn't map to
BlockingIOError.

> Would it be possible to have an (exhaustive?) list of errno with their
> popularity? At least, their popularity in the Python standard library?

How do you suggest to do that?

> Does raising a specific error (e.g. raise FileNotFound()) set errno and
> message attributes (to something different than None)?

No, it doesn't. "errno" should IMO only be set if it's truely returned
by a system routine. As for the message, like with every other exception
it should be supplied by the developer.

> Do specific errors slows down raising exceptions? Do raising an IOError
> (or a "legacy" error) use a O(1) lookup to choose the exception class?

It uses a dict. You could run some benchmarks if you want, but I doubt
it makes much sense to worry about that.

> EACCES and EPERM have a different meaning. Even that they are very
> similar, we might provide two different exceptions. EPERM is only used
> once in the Python stdlib, so we might only provide AccesError.
> 
> On Linux, EPERM usually indicates an operation requiring root
> priviledge.  EACCES can be related to filesystem permissions (read-only,
> user is not allowed to write, etc.) or can be an mmap error.

I'd have to research that a bit more. Perhaps EACCES can be mapped to
AccessError and EPERM to PermissionError, but I think the proximity of
the two concepts will make things confusing, for little benefit.

> Because IOError, OSError, select.error, etc. are well known exceptions,
> I'm not in favor of removing them from Python 3. It would make porting
> from Python 2 worse. If we don't remove them, they should not be
> deprecated.

Ok. Does anyone else have an opinion on deprecations?
(not deprecating them means less work for me, anyway)

> Test the implementation
> -----------------------
> 
> Did someone test Blender, Django or another major applications on the
> implementation of the PEP 3151?

Does Django have a working Python 3 port yet?

> WindowsError and winerror attribute
> -----------------------------------
> 
> I don't like the idea of having a winerror attribute platforms other
> than Windows.

Well, there isn't, as you can see in the tests
(test_windows_error in Lib/test/test_pep3151.py).

> shutil module uses:
> 
>      (...)
> 
>      try:
>          copystat(src, dst)
>      except OSError as why:
>          if WindowsError is not None and isinstance(why, WindowsError):
>              # Copying file access times may fail on Windows
>              pass

That's the kind of code the PEP hopes to discourage :)

> Lock.acquire() doesn't raise an exception on timeout: just remove "(for
> example in Lock.acquire())".

Oops, will fix.

> Should FileNotFound handle ENODEV? (see test_ossaudiodev)

That's not really the same thing. For example, mmap says:

[ENODEV]
    The fildes argument refers to a file whose type is not supported by
mmap().

(http://www.opengroup.org/sud/sud1/xsh/mmap.htm)

Regards

Antoine.