[Python-checkins] r47109 - peps/trunk/pep-3103.txt

[david.goodger]

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.