Python handles globals badly.
Skybuck Flying
skybuck2000 at hotmail.com
Fri Sep 11 17:50:38 EDT 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