On 7/7/06, Talin <[EMAIL PROTECTED]> wrote: > 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".
I think if my proposal as the former too; except for switches using locals, which I don't care about. I find the "unoptimization" if a local is involved rule very subtle -- it could even be used to force reevaluation of all cases (say, when there's some non-constant global involve) by inserting a case that's a local variable with an impossible value. Since sometimes things don't work as expected, and then you have to debug them using the full set of rules, I find simple a "implementation" (even if it's also formal semantics) important. > (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.) What's so hard to remember about the rule "cases should be constant"? > 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". Nor Pythonic. > (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.) I guess I used "functional" where I might have said "Scheme-ish" -- I meant excessive use of HOFs. -- --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
