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

Mon Jun 26 22:47:16 CEST 2006

On 2006年6月26日, Guido van Rossum wrote:
> Can you please edit the PEP yourself to add this? That will be most efficient.

I've done so, and tried to clarify the next line to match (see below).
> 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

Right. As written, the problem "a buggy hash might generate an
incorrect match" is not specific to School I; it's a problem with
any approach that is implemented by a hash lookup. School II is
necessarily implemented this way; School I might or might not be.
So i think the part that says:
 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
doesn't belong there, and i'd like your consent to remove it.
On the other hand, this criticism:
 if we generate code that catches errors in the hash to
 fall back on an if/elif chain, we might hide genuine bugs
is indeed specific to School I + hashing.
> 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;

Ok. Then there's an inconsistency with the definition of School I:
 School I wants to define the switch statement in term of
 an equivalent if/elif chain
To clear this up, i've edited the first line of the School II
paragraph, which previously said:
 School II sees nothing but trouble in that approach
It seems clear that by "that approach" you meant "trying to achieve
if/elif semantics while using hash optimization" rather than the
more general definition of School I that was given. I believe
there are a few voices here (and i count myself among them) that
consider the semantics more important than the speed and are in
School I but aren't treating hash optimization as the quintessence
of 'switch', and we shouldn't leave them out.
-- ?!ng