On 7/6/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > > So, my proposal is to give up on static, accept PEP 3103 with the > > following options: > > - Syntax alternative 2+B (unindented cases, 'case in ...' for multiple > > cases). > > - Semantics option 3 (def-time freezing) > > I agree with giving up on static, or at least treating > it as a separate issue from switch.
OK, this much is a deal then. > But there's one more thing I'd like to see discussed > concerning def-time freezing: > > apple = 1 > banana = 2 > > def f(): > ... > def g(fruit): > ... > switch fruit: > case apple: > ... > case banana: > ... > > With def-time freezing as currently proposed, this will > evaluate the cases inside g() every time f() is called. > But that would be wasteful, because they only depend on > names defined at the module level. > > So I'd like to propose that "def time" be modified > slightly to mean "def time of the outermost function > that is still inside the scopes containing all the > names that the case expressions depend on". Not > sure about the wording of that, but I hope you get the > idea. In the above example, that would be the def time > of f(), rather than g(). I get the idea, and I don't like it. I thought of this case before and decided that it really isn't worth the complexification (and I'm using that word intentionally :-) of the rules. We don't have any rules like that ATM, and it's not the kind of rule that is even close to anything we do have (I claim that the def-time rule *is* close to something we already have, i.e. parameter default values -- close, not the same, mind you). Somehow a switch doesn't really strike me as a typical idiom for functional programming, so I doubt that the issue will matter in practice; in order for this to make a difference you'd have to have an inner function containing a switch *and* the inner function must only be called once (or a small number of times) for each time it is defined *and* the user must give a damn about optimization. The combination of the first and second suggests a functional programming mindset which somehow makes the third less likely. 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. We can't store it in the outer function's local namespace (since it's not being called yet) so the only place to store it would be the outer function object. But that is not readily accessibly by the time the inner function object is being defined (the outer function's name is not a safe way to reference it). > I'd further suggest that a switch be allowed to reference > names in the current scope, in which case no optimisation > is done. That would take care of switches at the module > level, without making the module level a special case > with respect to the evaluation time rules. More complexification that I don't like. The only idiom I'm interesting in supporting is the one where the cases are constants (even though the compiler may not know it if they are named constants). 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 might as well repeat a quote I heard recently (and had heard before) from my good friend Brian Kernighan: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." 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. 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, which means that you can't be misled by a variable whose scope you are under- or over-estimating. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
