[Python-Dev] School IIb?

[Guido van Rossum]

On 6/26/06, Ka-Ping Yee <python-dev at zesty.ca> wrote:
> Here's a possible adjustment to the School-II approach that i think
> avoids the issues i've been raising, while giving the desired
> O(n)-to-O(1) speedup in common situations.  It's basically School-II
> dispatch, plus a check:
>
> On compilation, freeze any cases that meet the School-II conditions
> and have a trustworthy __hash__ method into a dictionary.  At runtime,
> when the dictionary yields a hit, check if the case expression yields
> a different value.  If the value has changed, use if/elif processing.
>
> In most cases the case-equality check will be cheap (e.g. an attribute
> lookup), but it would allow us to establish for sure that the switch
> value really matches the case value when we branch to a particular
> case, so we'd not be so vulnerable to __hash__ misbehaving, which
> seems to be your main source of discomfort with if/elif semantics.

I don't see how this can work for named constants, since their value
is unknown at compilation time.

I also don't like that you apparently are fine with all sort of
reorderings of the evaluation of the cases (the matching case is
always evaluated redundantly; other cases may be evaluate if the
optimization failed).

hash() misbehaving is not my main source of discomfort. It's the
messiness of trying to define rules that are as flexible as needed for
optimization and yet claiming to maintain the strict if/elif-chain
semantics. There's no messiness needed in the def-time-freeze rule;
the optimizer can't screw it, because the rule is so much simpler. The
code generator for optimized school I would be a beast.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)