[Python-checkins] peps: Fix use of "either" and typo in "checking" (Jim Jewett)
antoine.pitrou
python-checkins at python.org
Mon Apr 4 15:33:37 CEST 2011
http://hg.python.org/peps/rev/f65beac56930
changeset: 3854:f65beac56930
user: Antoine Pitrou <solipsis at pitrou.net>
date: Mon Apr 04 15:33:34 2011 +0200
summary:
Fix use of "either" and typo in "checking" (Jim Jewett)
files:
pep-3151.txt | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/pep-3151.txt b/pep-3151.txt
--- a/pep-3151.txt
+++ b/pep-3151.txt
@@ -83,12 +83,12 @@
A further proof of the ambiguity of this segmentation is that the standard
library itself sometimes has problems deciding. For example, in the
-``select`` module, similar failures will raise either ``select.error``,
-``OSError`` or ``IOError`` depending on whether you are using select(),
-a poll object, a kqueue object, or an epoll object. This makes user code
-uselessly complicated since it has to be prepared to catch various
-exception types, depending on which exact implementation of a single
-primitive it chooses to use at runtime.
+``select`` module, similar failures will raise ``select.error``, ``OSError``
+or ``IOError`` depending on whether you are using select(), a poll object,
+a kqueue object, or an epoll object. This makes user code uselessly
+complicated since it has to be prepared to catch various exception types,
+depending on which exact implementation of a single primitive it chooses
+to use at runtime.
As for WindowsError, it seems to be a pointless distinction. First, it
only exists on Windows systems, which requires tedious compatibility code
@@ -171,10 +171,10 @@
For this we first must explain what we will call *careful* and *careless*
exception handling. *Careless* (or "naïve") code is defined as code which
-blindly catches either of ``OSError``, ``IOError``, ``socket.error``,
-``mmap.error``, ``WindowsError``, ``select.error`` without cheking the ``errno``
+blindly catches any of ``OSError``, ``IOError``, ``socket.error``,
+``mmap.error``, ``WindowsError``, ``select.error`` without checking the ``errno``
attribute. This is because such exception types are much too broad to signify
-anything. Either of them can be raised for error conditions as diverse as: a
+anything. Any of them can be raised for error conditions as diverse as: a
bad file descriptor (which will usually indicate a programming error), an
unconnected socket (ditto), a socket timeout, a file type mismatch, an invalid
argument, a transmission failure, insufficient permissions, a non-existent
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list