[Python-Dev] Switch statement
python-dev at zesty.ca
Thu Jun 22 21:07:12 CEST 2006
On Wed, 21 Jun 2006, Guido van Rossum wrote:
> I worry (a bit) about this case:
> y = 12
> def foo(x, y):
> switch x:
> case y: print "something"
> which to the untrained observer (I care about untrained readers much
> more than about untrained writers!) looks like it would print
> something if x equals y, the argument, while in fact it prints
> something if x equals 12.
I am quite concerned about this case too. I think if Python were
to behave this way, it would be a new pitfall for people learning
the language -- like other pitfalls such as using unbound locals,
mutable default arguments, or the historical non-nested scopes.
I'm not saying the other pitfalls don't have good reasons -- some
are outweighed by other design advantages (unbound locals are a
consequence of having no variable declarations) and some have
since been fixed (like nested scopes). But i'd be wary of adding
a new pitfall to that list without a very substantial win.
> Me too. I guess I was just pointing out that "just" evaluating it in
> the global scope would not give an error, just like this is valid (but
> y = 12
> def foo(y=y):
> print y
> y = 13
> foo() # prints 12
I see how frozen-cases and default-arguments could have comparable
semantics, but i do think frozen-cases are more confusing. In this
default-arguments example, there is at least a hint from the syntax
that we're introducing a new local variable, so there is a landmark
where the reader can hang the mental note that a new thing is being
introduced. Also, it is easier to see that default arguments are
being fixed at function-definition time because their value
expressions are localized in the source code in the "def" line, a
line that makes sense to be evaluating at definition time.
For frozen-cases, you don't have this kind of landmark, and the bits
that are evaluated at function-definition time are scattered and
mixed with the rest of the function evaluated at function-call time.
That's pretty subtle; i can't think of any other Python construct
off the top of my head that mixes evaluation times like that. (Yes,
the compiler does optimize literals, but it's done in a way that
doesn't affect semantics.)
More information about the Python-Dev