Daniel. writes:
> IMHO, the most obvious solution is that the bind should be available only
> inside case block and if you need to change a global or a nonlocal you do
> this explicitly inside the case block,
Do you mean
case x:
x = x
?
> if this is the case you can pickup a bind name that doesn't shadow
> the desired variable.
But you can already do that in the case clause itself.
> This way the intention to overwrite a global/nonlocal is clear in
> code
But you can't "overwrite" a global or nonlocal without a declaration.
You can only shadow it, and as I wrote above, if you want to avoid
shadowing that global or nonlocal you choose a different name in the
case clause.
Regarding the proposal itself, it's a major change, because that's not
the way binding works anywhere else in Python. There are two
differences. The first is that there are no statements besides class
and def that create scopes, and the other two scopes that I know of
are module and comprehension (I seem to recall that comprehension
scope is based on the idea that the code inside the brackets is
actually syntactic sugar for a generator def, so that special case
would be derivative of function scope).
The second difference is that you can't change the binding of a name
in an outer local scope without a nonlocal declaration. That means if
case scope follows that rule and you want to have a binding inside the
case scope that persists outside it, you'd need to declare it.
Probably you don't want to have to declare those "external" names, so
the names bound by the case clause would be very special. I haven't
thought carefully about it, but it seems to me this could be a bug
magnet.
So, you could do this, but it would make scoping much more complex
than it currently is, and require a lot of redundancy (every binding
you want to preserve for later use would need to be made twice, once
in the case clause and again in the case body). And I don't think
it's that useful. It doesn't help with the I18N problem, since you
might want to use a marked string in the "case _" suite. And the main
complexity from the current scoping rules comes from the fact that it
seems likely that different arms of the match will bind different sets
of names, so NameErrors become more likely in the following code. But
your proposal doesn't help with that, and may make it more likely by
proliferating names.
Regards,
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/YDEORTNVLYXHX72FJ6CWXGZZ7C32ECKV/
Code of Conduct: http://python.org/psf/codeofconduct/
