On Wed, Aug 24, 2011 at 9:57 AM, Antoine Pitrou <solipsis@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@gmail.com | Brisbane, Australia