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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
