Before reflecting latest answers
a short absolute last statement about that matter:
Differ: globals (traditional, sharing vars app wide, NOT meant)
globals (module vars outside functions, meant here at least when I
mention this term)
global (the keyword used inside functions)
I did not say - make no comparions or no OO-wording. Sure, write what you have
to write
but hopefully especially as long as it changes not the topic of
this thread.
I did say - lay OO and sharing globals down (which again appears
and is NOT the topic (at least not mine)).
Point.
Reflecting latest answers, but not the new topic ("Progam in or into")
which has arrived , I want add following:
"""
Some statements brought into discussion (myself), read or skip down the closing
"""""
-- Comparison with Javscript:
Saying that Javascript and LUA does it samewise seems not correct
from reading the thread.
LUA is said it has it vice versa: local instead of a global
But Javascript does have neither local nor global keyword so far I know,
but has also a local scope (block scope).
The other Python-proposals aside "global":
-- switch statement:
PEP3103, it is PEP from Guido van Rossum!
I can only say: If even a "good and senseful" PEP from Guido is denied from
community I do better not comment.
-- indentation:
I am not sure if the sample has been changed from posting
but the line "count +=1" is clearly integrated
at the outer loop (at least in my browser)
(even process(line) is in that post in the outer loop)
No, I meant simply
count = 0
for file in files:
for line in open(file): # tab indent
process(line) # 2 space indent
count += 1
so, e.g. the first indent has 1 tab to the right, the second 2 spaces to the
right.
Why I am not free about this? Context is clear for me.
(I want not say I do this with intent, but if it happens: Ok, shit happens,
I need no script-error if it happens. Really not)
-- Universal scope
Yes proably ok.
you mean what builtins? Or What builtins suits best?
-- goto
I would say ok.
For the times you need such a construct it should be enough.
-- include statement
Not sure if we meant the same:
With including I meant the virtual merge of two or more scripts
(once merged it is executed as one script with one namespace:
a module var X in script A is directly available in script B,C,...)
Different is that including with namespaces is something special.
And if you search around the web there are different pseudo-includes proposals
(Side-effects unknown!?)
And with scopes, namespaces and every aspects to careof (memory, efficient file
reading,
compiled sources, caches) are something what should be provided from Python
itself
and should not be a construct from the developer.
According the Python philospophy ("one best way").
"""
Now back to the main topic:
-- "global"-keyword
Main point from my side is further (compared e.g. with Javascript)
Python needs the keyword "global" to give write access to a global(=module-var).
Only for that reason I would NOT need a "global" keyword
Though accepted that there are dynamic constructions which needs maybe a global
or even (but still not really believe) technical (compiler) reasons to have it
maybe,
but when rethinking it, escpecially about the dynamics constructs,
I still not really understand this reasons?:
At the risk of going in a circle:
Globals are of module-scope only.
I think it is NOT possible to have same var names xxx as global and
local(function-var)
and use them in parallel. Even with the sample provided:
exec("""def function():
global {0}
{0} = 42
""".format('x'))
For me this says that only: {0} is writeable. Nothing more,
No distinction needed if local or global.
Or is there an example out there where I really have to
distinct a same var name - inside a single module I would not know?
And even with more modules, than the distinction is done by namespace prefix.
I see no other value in the keyword "global" except the write-protection.
Proof:
Each sample provided would work without global (or you get runtime failure
while try to write a global).
So the compiler knows the distiction between global and local already.
Otherwise you would have to write in every function this keyword
But this is not the case. You write it because you need write access.
And this is an over-regulation. So, I say: NO need for an explicit global.
Optional ok.
Conclusion (for me):
--------------------
So for me the reasons about dynamic constructions or compiler thinks
aren'that revelant as described.
"global" is provided only to help the developer not to overwrite a global by
mistake,
and should be removeable if this protection is not wanted (by the community),
at least optional.
And this (and even the other points) would not change Python,
or is a matter of "Use Python language correct" or "try not to write Java".
Sure not.
I would rather say, this would enhance the power and flexibility of the Python
language even further.
Especially from the scripting point of view (without harm Python hardliner)
And by the way, I still believe that these changes would let Python overrun
Javascript and PHP.
There would practically no more any reasons for Javascript+NodeJS and
especially PHP.
I even think, a huge wave of developers would change then to Python.
Including webhosters which I think did not know or want not know anything about
Python 3.x.
Thanks.
--
https://mail.python.org/mailman/listinfo/python-list
