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