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

[ka-ping.yee]

Author: ka-ping.yee
Date: Mon Jun 26 22:48:07 2006
New Revision: 47110

Modified:
   peps/trunk/pep-3103.txt
Log:
Add a note on what School I finds risky about School II's approach.


Modified: peps/trunk/pep-3103.txt
==============================================================================
--- peps/trunk/pep-3103.txt	(original)
+++ peps/trunk/pep-3103.txt	Mon Jun 26 22:48:07 2006
@@ -307,13 +307,19 @@
 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 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 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 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;