[Python-Dev] PEP 3103: A Switch/Case Statement

[Guido van Rossum]

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
level.

>     (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/)