Add a note on what School I finds risky about School II's approach.

pep-3103.txt

@@ -307,13 +307,19 @@ There's also a school III which states that the definition of a switch
 statement should be in terms of an equivalent if/elif chain, with the
 exception that all the expressions must be hashable.
 
-School I believes that the if/elif chain is the only reasonably,
-surprise-free of defining switch semantics, and that optimizations as
-suggested by PEP 275's Solution 1 are sufficient to make most common
-uses fast.
+School I believes that the if/elif chain is the only reasonable,
+surprise-free way of defining switch semantics, and that optimizations
+as suggested by PEP 275's Solution 1 are sufficient to make most
+common uses fast.  School I sees trouble in the approach of
+pre-freezing a dispatch dictionary 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 sees nothing but trouble in that approach: in an if/elif
-chain, the test "x == y" might well be comparing two unhashable values
+School II sees trouble in trying to achieve semantics that match
+those of an if/elif chain while optimizing the switch statement into
+a hash lookup in a dispatch dictionary.  In an if/elif chain, the
+test "x == y" might well be comparing two unhashable values
 (e.g. two lists); even "x == 1" could be comparing a user-defined
 class instance that is not hashable but happens to define equality to
 integers.  Worse, the hash function might have a bug or a side effect;