From b143933fc2d0302ce0ad67fa893b95cc10d1ea80 Mon Sep 17 00:00:00 2001 From: Antoine Pitrou Date: Tue, 10 May 2011 18:31:19 +0200 Subject: [PATCH] Try to rephrase --- pep-3151.txt | 37 +++++++++++++++++++++++++------------ 1 file changed, 25 insertions(+), 12 deletions(-) diff --git a/pep-3151.txt b/pep-3151.txt index 139e6b06a..bd00d887d 100644 --- a/pep-3151.txt +++ b/pep-3151.txt @@ -510,19 +510,32 @@ 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. +One source of trouble is with the respective constructors of ``IOError`` +and ``WindowsError``, which were incompatible. The way it is solved is by +keeping the ``IOError`` signature and adding a fourth optional argument +to allow passing the Windows error code (which is different from the POSIX +errno). The fourth argument is stored as ``winerror`` and its POSIX +translation as ``errno``. The ``PyErr_SetFromWindowsErr*`` functions have +been adapted to use the right constructor call. -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. +A slight complication is when the ``PyErr_SetExcFromWindowsErr*`` functions +are called with ``IOError`` rather than ``WindowsError``: the ``errno`` +attribute of the exception object would store the Windows error code (such +as 109 for ERROR_BROKEN_PIPE) rather than its POSIX translation (such as 32 +for EPIPE), which it does now. For non-socket error codes, this only occurs +in the private ``_multiprocessing`` module for which there is no compatibility +concern. + +.. note:: + For socket errors, the "POSIX errno" as reflected by the ``errno`` module + is numerically equal to the `Windows Socket error code + `_ + returned by the ``WSAGetLastError`` system call:: + + >>> errno.EWOULDBLOCK + 10035 + >>> errno.WSAEWOULDBLOCK + 10035 Possible alternative