[Python-checkins] r47109 - peps/trunk/pep-3103.txt
david.goodger
python-checkins at python.org
Mon Jun 26 20:47:03 CEST 2006
Author: david.goodger
Date: Mon Jun 26 20:47:03 2006
New Revision: 47109
Modified:
peps/trunk/pep-3103.txt
Log:
typo fixes
Modified: peps/trunk/pep-3103.txt
==============================================================================
--- peps/trunk/pep-3103.txt (original)
+++ peps/trunk/pep-3103.txt Mon Jun 26 20:47:03 2006
@@ -42,7 +42,7 @@
- It is repetitive: the variable and the test operator, usually '=='
or 'in', are repeated in each if/elif branch.
-- It is inefficient: when an expressaion matches the last test value
+- It is inefficient: when an expression matches the last test value
(or no test value at all) it is compared to each of the preceding
test values.
@@ -67,7 +67,7 @@
My current preference is alternative 2.
-I should not that all alternatives here have the "implicit break"
+I should note that all alternatives here have the "implicit break"
property: at the end of the suite for a particular case, the control
flow jumps to the end of the whole switch statement. There is no way
to pass control from one case to another. This in contrast to C,
@@ -324,7 +324,7 @@
cases involving unhashable values; after all if the user expects such
values, they can just as easily write an if/elif chain. School II
also doesn't believe that it's fair to allow dead code due to
-overlappin cases to occur unflagged, when the dict-based dispatch
+overlapping cases to occur unflagged, when the dict-based dispatch
implementation makes it so easy to trap this.
School III admits the problems with making hash() optional, but still
@@ -368,7 +368,7 @@
the case expression. It has the advantage of being unambiguous and
easy to implement.
-My may complaint about this is that by disallowing "named constants"
+My main complaint about this is that by disallowing "named constants"
we force programmers to give up good habits. Named constants are
introduced in most languages to solve the problem of "magic numbers"
occurring in the source code. For example, sys.maxint is a lot more
@@ -377,10 +377,10 @@
can be the name that the constant would otherwise have. Thus, we
could write "case 'IGNORECASE':" instead of "case re.IGNORECASE:".
However, if there is a spelling error in the string literal, the case
-will silently be ignored, and who knows when the bug is detected. If
+will silently be ignored, and who knows when the bug is detected. If
there is a spelling error in a NAME, however, the error will be caught
as soon as it is evaluated. Also, sometimes the constants are
-externally defined (e.g. when parsing an file format like JPEG) and we
+externally defined (e.g. when parsing a file format like JPEG) and we
can't easily choose appropriate string values. Using an explicit
mappping dict sounds like a poor hack.
More information about the Python-checkins
mailing list