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

[Ka-Ping Yee]

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