Mark Hammond wrote: > 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]
The strerror for ESRCH is "No such process", which isn't really that reasonable. Breakage would occur, because people might currently check for ENOENT (or any other specific error code); if they don't see that specific error code, they will assume it is a "real" error. That said: I would actually expect that it is infrequent that people do look at the errno of a WindowsError, so breakage might be small. > 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... It would need to get suppressed when the value is merely displayed, atleast in the default __str__ implementation. Regards, Martin _______________________________________________ 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
