[Python-Dev] "DOS" error codes, WindowsError, and errno

[Mark Hammond]

Guido:
> What a mess. :-(
>
> WindowsError should have used a different name for the Windows-native
> error code, so we could have defined both separately without
> confusion.
>
> Is it too late to change WindowsError in that way?

I guess "too late" is purely a judgement call about breaking existing code.
One thing to our advantage is that I believe the most common errno
explicitly checked for will be ENOENT, which happily has the same value as
ERROR_FILE_NOT_FOUND.  [Actually, checking 2 *or* 3 (ERROR_PATH_NOT_FOUND)
is also common - but ESRCH==3, which sounds reasonable]

Another way forward may be to issue a warning whenever '.errno' or '[0]' is
referenced from WindowsError, noting that the semantics are soon to change,
and to use the new attribute if they really do want a win32 error code.  I'm
not sure how practical that is though...

Mark


>
> Unhelpfully,
>
> --Guido
>
> On 1/30/06, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> > I have a new implementation of stat/fstat/wstat which directly uses
> > Win32 API, rather than using msvcrt. This works fine so far, except
> > that error handling turns out to be tricky.
> >
> > mscvcrt maps errors (GetLastError()) into errno.h values, and also
> > preserves the original error code in _doserrno. Currently, stat()
> > will raise OSError, with errno set to the errno.h value.
> >
> > Because the Win32 error codes are much more fine-grained, this
> > conversion loses information. Python raises WindowsError in
> > some cases (e.g. os.listdir); WindowsError inherits from OSError,
> > but the errno attribute now must be interpreted as a Win32 error.
> > This is unfortunate, because the values overlap, and somebody
> > handling OSError might confuse the error codes for errno.h
> > (msvcrt) values.
> >
> > So what should I do in the new stat implementation? Try to map
> > error codes also? Raise WindowsErrors instead? Do something else
> > entirely?
> >