[Python-Dev] PEP 3103: A Switch/Case Statement (original) (raw)

Ka-Ping Yee python-dev at zesty.ca
Mon Jun 26 22:47:16 CEST 2006

On Mon, 26 Jun 2006, 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

More information about the Python-Dev mailing list