At 09:16 AM 6/21/2006 -0700, Guido van Rossum wrote:
>After thinking about it a bit I think that if it's not immediately
>contained in a function, it should be implemented as alternative
>syntax for an if/elif chain.
That worries me a little. Suppose I write a one-off script like this:
for line in sys.stdin:
words = line.split()
if words:
switch words[0]:
case "foo": blah
case words[-1]: print "mirror image!"
Then, if I later move the switch into a function, it's not going to mean
the same thing any more. If the values are frozen at first use or
definition time (which are the same thing for module-level code), then I'll
find the lurking bug sooner.
OTOH, breaking it sooner doesn't seem like such a great idea either; seems
like a recipe for a newbie-FAQ, actually. ISTM that the only sane way to
deal with this would be to ban the switch statement at module level, which
then seems to be an argument for not including the switch statement at all. :(
I suppose the other possibility would be to require at compilation time
that a case expression include only non-local variables. That would mean
that you couldn't use *any* variables in a case expression at module-level
switch, but wording the error message for that to not be misleading might
be tricky.
I suppose an error message for the above could simply point to the fact
that 'words' is being rebound in the current scope, and thus can't be
considered a constant. This is only an error at the top-level if the
switch appears in a loop, and the variable is rebound somewhere within that
loop or is rebound more than once in the module as a whole (including
'global' assignments in functions).
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
