From b6df74e01e36ac97f2aec59b8616186c2012ef75 Mon Sep 17 00:00:00 2001 From: Antoine Pitrou Date: Tue, 10 May 2011 17:54:07 +0200 Subject: [PATCH] Mention the rare issue of having a Windows error code exposed as the errno attribute of a non-WindowsError exception. --- pep-3151.txt | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/pep-3151.txt b/pep-3151.txt index fd2090551..139e6b06a 100644 --- a/pep-3151.txt +++ b/pep-3151.txt @@ -508,12 +508,21 @@ A reference implementation has been started in http://hg.python.org/features/pep-3151/ in branch ``pep-3151``. For now only `Step 1`_ is implemented, and without the deprecation warnings. However, it shows that coalescing the exception types doesn't produce any -significant annoyance in the standard library. The only observed trouble -is with the respective constructors of ``IOError`` and ``WindowsError``, -which are slightly incompatible. The way it is solved is by keeping the -``IOError`` semantics and adding a fourth optional argument to allow passing -the Windows error code (which is different from the POSIX errno). All -``PyErr_SetFromWindowsErr*`` functions do the right thing. +significant annoyance in the standard library. + +The only observed trouble is with the respective constructors of ``IOError`` +and ``WindowsError``, which are slightly incompatible. The way it is solved +is by keeping the ``IOError`` semantics and adding a fourth optional argument +to allow passing the Windows error code (which is different from the POSIX errno). +All ``PyErr_SetFromWindowsErr*`` functions do the right thing. + +An issue is when the ``PyErr_SetExcFromWindowsErr*`` functions were called +with an exception type which is neither ``WindowsError`` nor a subclass of it: +for example an ``IOError`` whose ``errno`` attribute ended up storing +a Windows error code rather than its POSIX translation - for example +ERROR_BROKEN_PIPE (109) rather than EPIPE (32). Since native Windows error +codes are not exposed by the standard library for matching by third-party code, +such instances should only be found in our own code, and easily fixed. Possible alternative