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

[guido.van.rossum]

Author: guido.van.rossum
Date: Tue Jun 27 20:01:47 2006
New Revision: 47132

Modified:
   peps/trunk/pep-3103.txt
Log:
Standardize case of "school" -- there's no reason to capitalize this everywhere.


Modified: peps/trunk/pep-3103.txt
==============================================================================
--- peps/trunk/pep-3103.txt	(original)
+++ peps/trunk/pep-3103.txt	Tue Jun 27 20:01:47 2006
@@ -294,12 +294,12 @@
   dict.  There are different choices for when the precomputation
   happens.
 
-- There's also school III, which agrees with School I that the
+- There's also school III, which agrees with school I that the
   definition of a switch statement should be in terms of an equivalent
   if/elif chain, but concedes to the optimization camp that all
   expressions involved must be hashable.
 
-We need to further separate School I into School Ia and School Ib:
+We need to further separate school I into school Ia and school Ib:
 
 - School Ia has a simple position: a switch statement is translated to
   an equivalent if/elif chain, and that's that.  It should not be
@@ -307,7 +307,7 @@
   against this school: without any hint of optimization, the switch
   statement isn't attractive enough to warrant new syntax.
 
-- School Ib has a more complex position: it agrees with School II that
+- School Ib has a more complex position: it agrees with school II that
   optimization is important, and is willing to concede the compiler
   certain liberties to allow this.  (For example, PEP 275 Solution 1.)
   In particular, hash() of the switch and case expressions may or may
@@ -323,27 +323,27 @@
 found cases isn't so easy, and that it's better to face this head on.
 This will become clear below.
 
-The differences between School I (mostly School Ib) and School II are
+The differences between school I (mostly school Ib) and school II are
 threefold:
 
 - When optimizing using a dispatch dict, if either the switch
   expression or the case expressions are unhashable (in which case
-  hash() raises an exception), School Ib requires catching the hash()
+  hash() raises an exception), school Ib requires catching the hash()
   failure and falling back to an if/elif chain.  School II simply lets
   the exception happen.  The problem with catching an exception in
-  hash() as required by School Ib, is that this may hide a genuine
+  hash() as required by school Ib, is that this may hide a genuine
   bug.  A possible way out is to only use a dispatch dict if all case
   expressions are ints, strings or other built-ins with known good
   hash behavior, and to only attempt to hash the switch expression if
   it is also one of those types.  Type objects should probably also be
-  supported here.  This is the (only) problem that School III
+  supported here.  This is the (only) problem that school III
   addresses.
 
 - When optimizing using a dispatch dict, if the hash() function of any
   expression involved returns an incorrect value, under school Ib,
   optimized code will not behave the same as unoptimized code.  This
   is a well-known problem with optimization-related bugs, and waste
-  lots of developer time.  Under School II, in this situation
+  lots of developer time.  Under school II, in this situation
   incorrect results are produced at least consistently, which should
   make debugging a bit easier.  The way out proposed for the previous
   bullet would also help here.
@@ -368,18 +368,18 @@
   duplicate cases (i.e. two or more cases with match expressions that
   evaluates to the same value).  School I wants to treat this the same
   is an if/elif chain would treat it (i.e. the first match wins and
-  the code for the second match is silently unreachable); School II
+  the code for the second match is silently unreachable); school II
   wants this to be an error at the time the dispatch dict is frozen
   (so dead code doesn't go undiagnosed).
 
-School I sees trouble in School II's approach of pre-freezing a
+School I sees trouble in school II's approach of pre-freezing a
 dispatch dict because it places a new and unusual burden on
 programmers to understand exactly what kinds of case values are
 allowed to be frozen and when the case values will be frozen, or they
 might be surprised by the switch statement's behavior.
 
-School II doesn't believe that School Ia's unoptimized switch is worth
-the effort, and it sees trouble in School Ib's proposal for
+School II doesn't believe that school Ia's unoptimized switch is worth
+the effort, and it sees trouble in school Ib's proposal for
 optimization, which can cause optimized and unoptimized code to behave
 differently.