Python handles globals badly.

[Ian Kelly]

On Fri, Sep 11, 2015 at 3:26 PM,  <tdev at freenet.de> wrote:
> Ad hominem.
> There is a slogan: "There are always two persons involved"
> This I dont want talk about. I dont go into such a discussion.
> It seems more a problem of misinterpretations.

I think you misunderstand my comment. The paragraph that I was
responding to commits the ad hominem logical fallacy by supposing that
the credentials of the person making an argument have any bearing on
the validity of the argument. It therefore is dismissed as being
poorly reasoned. I point this out not to criticize, but to point out
that your argument is fallacious.

> But you can say, the "general" sample is:
> You have to specify global that the compiler can distinguish
> between local and global
> Other words: global is needed to distinct global from local.

This is not what I would consider a sample. I thought you were
referring to actual code examples demonstrating something.

> But this is "not" true.
> You specify global cause you want write access.
> Even the rules specified proves it:
>
>> 1) If it's in the function's argument list, it's an argument (and
>> therefore local).
>> 2) If it's explicitly declared global, then it's global.
>> 3) If it's never assigned within the function, then it's global.
>> 4) Otherwise, it's local.
>
> Take step 2 out than it is again recognized as global.
> So the global keyword is not needed to distinguish global from local.
> Rule 3 proves it.

Rule 3 works because it's generally safe to assume that a variable
that is never assigned locally can't be local; any attempt to access
it would result in an UnboundLocalError. (I say "generally" because
this assumption only holds as long as it's not possible to set locals
via eval or by updating locals(). That's true in the C implementation
of Python but not necessarily true in other implementations.)

Rule 3 doesn't imply that the compiler is capable of distinguishing
globals from locals. It's a guess based on a rule of thumb. So it's
less accurate to say that "you specify global cause you want write
access" and more accurate to say that "you specify global in cases
where the compiler can't guess it without assistance". It just so
happens that the two line up with one another.

> Surprisingly this runs now.
> Sometimes I run into indentations errors similiar to sample above for no reasons
> (maybe cause of existing spaces on the end of a line - next occurences I will try to note it down)
> But I have to remove this proposal for now.
> Sorry.

Yes, you can already choose between tabs or spaces for indentation.
You just can't mix them within the same code block.