[Python-Dev] PEP 3103: A Switch/Case Statement
Guido van Rossum
guido at python.org
Mon Jun 26 22:06:24 CEST 2006
On 6/26/06, Ka-Ping Yee <python-dev at zesty.ca> wrote:
> On Mon, 26 Jun 2006, Guido van Rossum wrote:
> > I've written a new PEP, summarizing (my reaction to) the recent
> > discussion on adding a switch statement. While I have my preferences,
> > I'm trying to do various alternatives justice in the descriptions.
> Thanks for writing this up!
> The section that most draws my attention is "Semantics", and i guess
> it isn't a surprise to either of us that you had the most to say
> from the perspective you currently support (School II). :) Let me
> suggest a couple of points to add:
> - School I sees trouble in the approach of pre-freezing a dispatch
> dictionary because it places a new and unusual burden on the
> programmer to understand exactly what kinds of case values are
> allowed to be frozen and when the case values will be frozen.
Can you please edit the PEP yourself to add this? That will be most efficient.
> - In the School II paragraph you say "Worse, the hash function
> might have a bug or a side effect; if we generate code that
> believes the hash, a buggy hash might generate an incorrect
> match" -- but that is primarily a criticism of the School II
> approach, not of the School I approach as you have framed it.
> It's School II that mandates that the hash be the truth.
You seem to misunderstand what I'm saying or proposing here;
admittedly I think I left something out. With school I, if you want to
optimize using a hash table (as in PEP 275 Solution 1) you have to
catch and discard exceptions in hash(), and a bug in hash() can still
lead this optimization astray: if A == B but hash(A) != hash(B),
"switch A: // case B: ... // else: ..." may falsely take the else
branch, thereby causing a hard-to-debug difference between optimized
and unoptimized code. With school II, exceptions in hash() aren't
caught or discarded; a bug in hash() leads to the same behavior as
optimized school I, but the bug is not dependent on the optimization
> (It looks to me like what you're actually criticizing here is
> based on some assumptions about how you think School I might
> be implemented, and having taken School I a number of steps
> down that (unexplained) road you then see problems with it.)
Right. School I appears just as keen as school II to use hashing to
optimize things, but isn't prepared to pay the price in semantics; but
I believe the optimizations are impossible to behave completely
identically to the unoptimized code (not even counting side effects in
hash() or __eq__()) so I believe the position that the optimized
version is equivalent to the unoptimized "official semantics"
according to school I is untenable.
> Also, why is the discussion of School II mostly an argument against
> School I? What about describing the advantages of each school?
School II has the advantage of not incurring the problems I see with
school I, in particular catching and discarding exceptions in hash()
and differences between optimized and unoptimized code.
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev