[Python-3000] Switch and static, redux

[Talin]

Greg Ewing wrote:
> 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.

I'm in agreement with Greg here - his version sounds easier to 
understand, with less hidden gotchas. I would rather have "it always 
works with the same semantics, but some cases are slower than others", 
than "it only works in some cases". (And to turn Guido's argument on its 
head, if you 'give a damn' about optimization, then you probably care 
enough to track down the underlying causes. But for everyone else, it 
should 'just work', and no detective work required as to deciding what 
kinds of case values are legal or not.)

And I agree that inner functions != functional programming. As Ping 
pointed out, closures pretty much required in Javascript programming 
(especially if you are doing AJAXy stuff), but I doubt most people would 
consider that "functional".

(Strictly speaking, one of the defining characteristics of functional 
programming is that there be no side effects - which is exactly the 
opposite of the way most Python programmers use inner functions.)

-- Talin