[Python-Dev] Comments of the PEP 3151

[Victor Stinner]

On 25/07/2011 02:24, Antoine Pitrou wrote:
>
> 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 asked if:

try:
  ...
except FileNotFound:
    pass

is faster than:

try:
  ...
except IOError as err:
    if err.errno != errno.ENOENT:
       raise
    else:
       pass

f an IOError with errno != ENOENT is raised.

>> 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.

"The list is not cast in stone." : ok :-)

>> 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.

Ok, so let add InterruptError.

>> 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?

Use the list of all errno from the Appendix A, and then count the number 
of occurence in the Python source code (excluding the test suite). You 
can for example using a shell for that:

$ grep -h -c EINVAL $(find -name "*.py"|grep -v Lib/test)|grep -v '^0$'
1
1
2

These numbers give an approximation of the popularity of the different 
errno.

>> Does raising a specific error (e.g. raise FileNotFound()) set errno and
>> message attributes (to something different than None)?
>
> No, ... As for the message, like with every other exception
> it should be supplied by the developer.

Ok, I agree.

>> 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.

Ok, a dict should be fast.

>> 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.

You are probable right.

>> 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

Oh, it's not clear in the PEP.

>> Should FileNotFound handle ENODEV? (see test_ossaudiodev)
>
> That's not really the same thing.

Ok.

Victor