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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
