On 6/27/20 5:36 AM, Stephen J. Turnbull wrote:
> Richard Damon writes:
> > I thought _ was also commonly used as:
> > first, -, last = (1, 2, 3)
> > as a generic don't care about assignment.
> It is. But there are other options (eg, 'ignored') if '_' is used for
> translation in the same scope.
> > I guess since the above will create a local, so not overwrite a
> > 'global' function _ for translations, so the above usage works as
> > long as that function (or whatever namespace you are in) doesn't
> > use _ for translations.
> > As long as the bindings in match also make the symbol a local
> > (which seems reasonable) then you would get a similar restriction.
> It's quite different. First, it surely won't make other symbols
> match-local. Of course there will be times when you do all the work
> inside the match statement. But often you'll want to do bindings in a
> match statement, then use those outside. The second problem is that
> this use of '_' isn't optional. It's part of the syntax. That means
> that you can't use the traditional marking of a translateable string
> (and it's not just tradition; there is a lot of external software that
> expects it) in that scope.
> So it's practically important, if not theoretically necessary, that
> 'case _' not bind '_'.
I wasn't imply local to the match statement, but if the match is used
inside a function, where using the binding operatior = will create a
local name, even if there is a corresponding global name that matches
(unless you use the global statement), will a match statement that binds
to a name that hasn't bee made a local name by having an explicit
assignment to it, actually bind to a global that might be present, or
will it create a local? My first feeling is that binding to the global
would be surprising.
foo = 1
case 1: print('baz was one')
case foo: print('baz was ', foo)
will this script create a new foo name inside bar, so that when we
return, the module global foo is still 1, or did be bind to the global
and change it?
Rebinding a global without a global statement would be unexpected
(normally we can mutate the global, but not rebind it)
Python-Dev mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Message archived at https://email@example.com/message/A2YKBTEHILHRNLN62LIPNAXCDG73ACD6/
Code of Conduct: http://python.org/psf/codeofconduct/
I think that global binding make no sense, it will break a lot of code silently, think about this
case bar: pass
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, if this is the case you can pickup a bind name that doesn't shadow the desired variable. This way the intention to overwrite a global/nonlocal is clear in code
“If you're going to try, go all the way. Otherwise, don't even start. ..."