> Then the function should not use the global variable at all without explicitly indicating it
Generally you use `global` to handle this.
> I do find it humorous that the global variable is semi-protected in python, while the variable type is not.
It's not, there are no differences between them. Bindings (names) are captured like most other languages, and you're free to overwrite them if you wish.
In your example you bind a new string to an existing name. I think it's pretty expected that this wouldn't suddenly change the global object to a local one, that would be madness.
But you're free to update the object _referenced_ if it's mutable:
Assigning is different than appending, and is the case with a syntax ambiguity. But I'm also not a big fan of the implicit `global` in your example if it's not always implicit.
Fine, we want a test by using `global` to make sure we are doing what we intend when we assign, especially since I see python does not even have true constants so there is a basic lack of safety there. There should also be similar tests before passing every variable with the same name through our function and treating a single name as a list of references without a keyword `all` or similar. Or changing the type of a variable without explicit casting.
To me that lack of continuity just makes a language feel idiomatic and buggy.
Generally you use `global` to handle this.
> I do find it humorous that the global variable is semi-protected in python, while the variable type is not.
It's not, there are no differences between them. Bindings (names) are captured like most other languages, and you're free to overwrite them if you wish.
In your example you bind a new string to an existing name. I think it's pretty expected that this wouldn't suddenly change the global object to a local one, that would be madness.
But you're free to update the object _referenced_ if it's mutable: