On Wed, Aug 24, 2011 at 9:57 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> I don't have any personal preference. Previous discussions seemed to
> indicate people preferred IOError. But changing the implementation to
> OSError would be simple. I agree OSError feels slightly more right, as
> in more generic.
IIRC, the preference for IOError was formed when we were going to
deprecate the 'legacy' names. Now that using the old names won't
trigger any kind of warning, +1 for using OSError as the official name
of the base class with IOError as a legacy alias.
>> And that anything
>> raising an exception (e.g. via PyErr_SetFromErrno) other than the new ones
>> will raise IOError?
>
> I'm not sure I understand the question precisely. The errno mapping
> mechanism is implemented in IOError.__new__, but it gets called only if
> the class is exactly IOError, not a subclass:
>
>>>> IOError(errno.EPERM, "foo")
> PermissionError(1, 'foo')
>>>> class MyIOError(IOError): pass
> ...
>>>> MyIOError(errno.EPERM, "foo")
> MyIOError(1, 'foo')
>
> Using IOError.__new__ is the easiest way to ensure that all code
> raising IO errors takes advantage of the errno mapping. Otherwise you
> may get APIs raising the proper subclasses, and other APIs always
> raising base IOError (it doesn't happen often, but some Python
> library code raises an IOError with an explicit errno).
It's also the natural place to put the errno->exception type mapping
so that existing code will raise the new errors without requiring
modification. We could spell it as a new class method ("from_errno" or
similar), but there isn't any ambiguity in doing it directly in
__new__, so a class method seems pointlessly inconvenient.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4