Python handles globals badly.

tdev at freenet.de tdev at freenet.de
Fri Sep 11 23:26:58 CEST 2015


Reflecting latest answers to global and "proposals"


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.


Proofs. 
Not really proofs. I meant more or less proofs. Proofs in "Proofs".
Proofs from my point of view or you can say from my understanding 
(or say also high level position view) and from the answers given so far


Samples 
(+main discussion "global"). 
Samples are often as text only in this thread. 
I think it is clear when you have followed the thread.
But the thread has now taken some new directions.
Yes, it is litte awkward searching back now.

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.

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.



Identation.
It is stated
> It is correct that there have to be a decision for spaces or tabs.

With that I meant clearly no mixing of tabs and spaces.
So forget tabs (tabs changed to spaces) and take spaces.

The meaning is clearly:

def x():
  pass         2 spaces to the right

def y():
   pass        3 spaces to the right


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.


PEP.
As previously stated I am not in the position (and/or knowledge)
to write a PEP. I wanted only to start a general (high-level point of view) 
discussion about it, in the hope there is somehow an agreement which starts 
somehow a PEP.

But from answers in this list I would say: No chance.
Practically no agreements. This I have to accept, although 
I cannot understand it (reasons given in previous post:
it was/is nothing more than to enhance and give even more flexibility 
to the language as with all the other features already available in 
parallel for the same reasons).


Conclusion.
I will use Python, but never become a Pythonier, 
although quite conform with its philosophy "One best way".
But even a traditional switch is denied, although much clearer
in reading and writing than any if-else construct.
I can and will not understand it.


Thanks for your answers.




More information about the Python-list mailing list