[Python-Dev] Switch statement (original) (raw)

Ka-Ping Yee 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 confusing):

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.)

-- ?!ng

More information about the Python-Dev mailing list