Richard Damon writes:
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?
All names are global, in some relevent sense. It's the bindings to objects that are scoped, and a binding in an inner scope shadows that of an outer scope. This just works, as I'm sure you've experienced. In this case, the match statement will create a binding in the current scope (in the case you present, local scope for that function). The problem for internationalization is not your example:
case 1: print('baz was one')
case foo: print('baz was ', foo)
but this kind of situation:
match baz: case 1: print(_('baz was one')) case _: print(_('baz was '), _(foo))
where _() marks a string that should be translated to another language, and also implements the lookup at runtime. If "case _" binds "_", the _() in the print statement in that arm of the match will very likely raise, and later _() will as well, until the end of the scope. It's very unlikely it will do what's desired!
Do translatable strings have to be marked with _()? In theory, no, in fact "_" is an alias for the gettext function, which could also be used. But in practice the marking aspect is used by a wide variety of translation support software searching for strings to translate, and it's also important to the readability of strings in the source that the mark be as lightweight as possible. So for internationalization it's useful that "case _" does not bind an object to the name "_".
It's a very special case, and it's fortunate that it works out this way that there's no conflict between the two uses of "_". Or maybe Lady Fortune is Dutch. :-)