iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

typo fixes

This commit is contained in:
David Goodger 2006-06-26 18:47:03 +00:00
parent 7f604edfe7
commit c9d10b37d0
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
pep-3103.txt
View File

@ -42,7 +42,7 @@ syntax for this idiom:
- 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 @@ they add anything.
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 @@ genuine bugs. In addition, school II sees little value in allowing
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 @@ a syntax where only a single literal of certain types is allowed as
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 @@ instead of named "enums", observing that the string literal's content
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.