Genstein <genstein <at> invalid.invalid> writes:
>
> > Andrew Berg<bahamutzero8825 <at> gmail.com> writes:
> > Since Python 2.5, the errno attribute maps the Windows error to error
> > codes that match the attributes of module errno.
>
> Good point, I completely misread that. At least the Windows error code
> is still available as the winerror attribute.
>
> As an aside - call me stupid, but I don't quite follow the purpose of
> that errno mapping. Surely if the error number can be mapped
> successfully then the error isn't Windows specific and an OSError should
> logically be thrown instead? And if it can't be mapped successfully then
> errno will never be valid so the mapping is pointless?
Since WindowsError is a subclass of OSError, .errno has to be there (and it
must
contain the UNIXy error code). You could then ask why it's a subclass in the
first place. I think part of the answer is that the docs are wrong --
presumably actual usage is that WindowsError is raised when a Windows API call
is made that *may* result in an exception that has no corresponding errno value
("presumably" because I'm writing on Linux & sourceforge is too slow for me
today to grab pywin32). In other words, code that raises WindowsError doesn't
try to test the error code so that it can raise OSError instead some of the
time. I don't think there would be any benefit in doing that, and it would
have
the disadvantage that with those calls, you'd have to deal with a mixture of
Windows and UNIXy error codes.
The presence of .errno, aside from being required (to satisfy LSP), does mean
you don't have to deal with the Windows codes if you're only interested in
cases
covered by module errno.
John
--
http://mail.python.org/mailman/listinfo/python-list
