Python handles globals badly.

Skybuck Flying skybuck2000 at hotmail.com
Fri Sep 11 23:50:38 CEST 2015


Hello,

I'll add some arguments to the global discussion for you.

First a look back at the origin of this "global" keyword, basically it's 
idea behind it, which is probably a flawed assumption.

The origin/purpose of global as I now understand it is to give "write" 
access to globally declared variables.

This is first of all something unusual. Which other programmer language has 
this weird/whacky inconsistency ?

In general I believe inconsistent behaviour should be prevented in 
programming languages.

Anyway... having written/said that... there is a flawed assumption with this 
idea.

The assumption is that: "writing to globals is bad and can lead to bugs".

The further assumption is that: "denieing write access to globals prevents 
bugs".

Especially the last assumption is just plain wrong.

Not giving write access to globals can also lead to even much harder to find 
bugs.

The unaware programmer may assume that a global was changed, while in 
reality it was not.

How will such a bug be found ? Very hard to do in general, especially in an 
interpreter like python... where these bugs will need to be catched at run 
time.

Catching these bugs at runtime is far more difficult than bugs/errors which 
show up during compile time.

Thus forgetting "global" is going to be a far worse mistake... then actually 
overwritten or re-using some global accidently.

This kind of mistake can be checked by the programmer without requiring 
runtime inspection.

As soon as the programmer notices that some global is being re-used 
abusively the programmer can correct the situation.

With forgetting the global keyword not so... much harder to find.

Only possibility is to add "global" everywhere out of paranoya... which 
prevents the programmer from having to inspect every possibly line of code.

The global/write access requirement right now basically forces the 
programmer to check EVERY line of python code to see if a global is being 
written to which actually does not have the required write permission ?!?

How can anybody in their right mind think that is is somehow an improvement 
? It simply is not... unless the interpreter at runtime would start to BEEP 
or show ERROR messages in some log... that a global is being written too 
which actually does not have WRITE permissions ?

So far I have only used Sikuli to develop in Python... so let me ask a 
question here: Is there ANY Python IDE that actually produces such a warning 
or error message at runtime ????

Is there any IDE which outputs:

"Error: GLOBAL variable being written too without WRITE permission ?!?".

How would the interpreter know that it is a global variable ? Well it's 
declared somewhere outside the scope of the function... so that's not the 
issue... issue is missing GLOBAL declaration inside the function... so it's 
more of a "WRITE" permission than "global permission".

So the name itself: "GLOBAL" is somewhat misleading... it's more a "WRITE" 
permission lol.

Just that reason alone is enough to remove "GLOBAL" from python language and 
replace it with: "WRITE".

or if it has to be: "GLOBAL-WRITE".

But any programmer would probably find that ridicilous.

So that basically proves that this GLOBAL requirement in itself is pretty 
ridicilous... though it does give a nice hint that this variable is a global 
variable ?! But is that really necessary ?!?

Perhaps, perhaps not... in PASCAL one would simply look at the top section 
of the function... where all variable must be declared, python lacks this 
feature which is kinda nice... but it does make it a bit problematic to spot 
if something is local or global.

While the next best thing the python programmer can do is: inspect the 
entire function to see if the variable is being written to or read from 
somewhere... but in reality this is no garantuee that it is local or 
global... so hence a little bit of a problem... adding global to the 
language is not really going to solve that... since programmer will have to 
add that manually to a variable... might forget it... and then the variable 
will actually still be a global variable.. and any bug fixer will still need 
to inspect code.

So basically this global requirement doesn't really help that much... as 
some say... it's a bit of a hint... a shitty one for that... it's almost 
like fuzzy logic... 50% chance that it's gonna help... 50% it's not gonna 
help ;) or might even lead to problems if read-only behaviour was actually 
required.

So when it comes to assumptions which bug is worse:

1. Willfully writing to a read-only global variable. (assignment failed-bug)
2. Mistakenly writing to a writeable global variable. (overwrite-bug)

As I already wrote before I think bug1 is much harder to spot then bug 2 by 
pure code inspection.

Ask yourself one question:

How many times does a programmer actually want a "read-only" global variable 
? This seems very weird to me.

Pascal solves this very nicely for "constants" with constant declaration.

If a global variable is to remain "read-only" then a better approach would 
be pascal's way:

Simply declaring the global variable as "constant"

constant MyGlobal = 5

Writing to MyGlobal would then produce an error.

This can probably be checked at compile time too.

Something which python does not seem to do currently ?!

So that's weird.

I will leave it at that for now.

Bye,
  Skybuck. 



More information about the Python-list mailing list