[Python-3000] Switch and static, redux

Guido van Rossum guido at python.org
Sat Jul 8 05:49:48 CEST 2006


On 7/7/06, Talin <talin at acm.org> 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/)


More information about the Python-3000 mailing list