Try to rephrase

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
+   <http://msdn.microsoft.com/en-us/library/ms740668%28v=vs.85%29.aspx>`_
+   returned by the ``WSAGetLastError`` system call::
+
+    >>> errno.EWOULDBLOCK
+    10035
+    >>> errno.WSAEWOULDBLOCK
+    10035
 
 
 Possible alternative