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" <[EMAIL PROTECTED]> 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? > > _______________________________________________ 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
