[Python-3000] Switch and static, redux

[Greg Ewing]

Guido van Rossum wrote:

> The
> combination of the first and second suggests a functional programming
> mindset which somehow makes the third less likely.

You seem to be conflating "nested functions" and
"functional programming", which doesn't make sense
to me.

> Your suggestion also makes it hard to find a good place to store the
> dispatch dict between the time the outer function is defined and the
> time the the inner function is defined.

Not at all -- you store it in a cell in the environment
of f(). In other words, you treat it like

   _g_cases = {...} # build the case dict

   def f():
     ...
     def g():
       ...
       # switch using _g_cases

> Having a rule that prescribes optimization depending on
> the scopes of variables involved in a set of expressions sounds like a
> recipe for hard to debug bugs (since these rules are so subtle).

I don't mean that optimisation would be forbidden, just
that it wouldn't be guaranteed if you use local names.
I don't see that as being any worse than the situation
now where, e.g. a loop written at the module level tends
to be slower because it's using globals for its variables.

I don't think there's anything particularly subtle about
this, either. If the cases are based on the values of
local variables, it seems pretty obvious that they're
going to be recomputed every time you enter the function.

> The changes to the rules that you are proposing make me think that we
> are making the rules too "clever", which will making it that much
> harder to debug issues around this.

As you've said yourself, the use cases for all this are
ones where the case values are effectively *constant*.
Given that, it doesn't matter a damn how early or late
they're evaluated, except insofar as it affects execution
speed. What I'm proposing is a rule that says, "We don't
guarantee to make it fast, but we'll try, and the more global
your case values are, the faster we're likely to be able to
make it".

> The much simpler rule that I
> propose is simpler to debug because you don't have to know the scope
> of the variables involved to know when the switch is frozen,

But you shouldn't *have* to know exactly when it's frozen
if your case values are constant, as they should be.

--
Greg