Re: Python handles globals badly.
I agree with Skybuck Flying. I am aware if a var is a module function var or a module global var. If I want read or write a global var. Using the keyword global inside each(!) function only to mark the global var writeable in each of the functions is really an over-regulation and very annoying from my point of view. Especially cause a module is a singleton. And globals are only module aware vars. Even Java (type-safe language) need not such things for its static or member vars. I have disliked this already in PHP where one has to do exact the same thing as in Python (and hoped Python does it better, but not). And using an import here is no solution, cause this is something which relates only to the scope and state of a module itself. I therefore would like to see a PEP which allows also writing global module vars inside module functions without the need for explicit setting the keyword "global" in more or less each(!) module function as the first line of code. I hope a lot can/will agree and a new PEP will arise to give this small responsibility back to the developer. Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
And to clarify: I have not spoken about sharing constants global (spanning over modules), where the solution provided here using imports is the solution. I have spoken from module vars which are named or are "globals" and its read/write access constraints inside module functions. So even the naming "globals" is something what I dislike, cause it is about module scope. With all other I can agree with Skybuck Flying too: "There is so far nothing else annoying!" (Maybe a missing switch statement). Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Reflecting the answers I want to add following: Considering class usage is something I thought about but is not the way I want use Python so far. If so, I could stay on oo-scripting languages as well. It is the good idea of Python about modules which are singletons and therefore have already its state (so in some way they are already somehow like classes - except the bad annoying thing with the "global" statement). That said, it is not an overusing of globals cause globals are module vars only. Or have you never written singletons or other classes in e.g Java, C++ with lots of static and class members and methods using this members. With globals in Python are not meant traditional globals (app spanning vars) as already said. Globals in Python are like class-members and statics in OO-languages. Globals are module scope! And therefore it is not the devil or evil problem or code desaster problem or LUA's opposite approach. (local/nonlocal statements I think are needed cause of lambda functionality and is not what I try to discuss here) Hopefully this clarifies a bit more my point of view and you can now agree that using "global" is not only over-regulated but also ugly code. At least the developer should be free to use the "global"-statement (if one really need this?) or not (myself, and hopefully a lot other). Therefore still hoping a new PEP will arise. @Mark Lawrence This response I have not checked. Can you provide arguments or clarify your statement? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Reflecting the answers I want to add following first:
I should have better started a new thread.
But now it is here, I want just clarify something before
I move on (later) with repsonding.
I think this has lead to some confusing.
There are now two main topics in this thread.
First topic:
"sharing globals between modules"
Where globals is meant as vars used throughout the app.
This is the topic why Skybuck starts the thread.
And yes I agree globals can be bad design
and it is solved via outsourcing to an extra module and used via imports.
I misinterpreted this topic a little by thinking
the focus is more about the use of the badly "global" keyword
(in my point of view) and added therefore my post here as
Second topic:
"Forced to use "global" for write-access inside functions
is over-regulation and should be removed."
This topic has nothing todo with sharing globals.
It is about in the scope of a single module only.
When I have written globals in this topic
I have meant and mean vars defined in a module outside
functions and used inside function blocks.
Sorry if this has lead to confusion, but so long
I have read docs I would say that these vars are
often named as globals although I meant module vars.
Reason is that module scope is the highest
scope and often referred as the global scope.
That is also why I dislike the word "global" too.
I talk about this construct:
Sample "Bad":
module A
_x = 0
def y():
global x
_x=1
and I aim for - it would be nicer to allow for simplicity
writing this without the keyword "global"
and give this small responsibility ("write protection")
back to the developer:
Sample "Good":
module A
_x = 0
def y():
_x=1
why - this I have tried and try to explain in my and your posts
in the hope a PEP will arise which frees me and hopefully
a lot other developers getting forced to use "global"
(If developers need this "global" - ok, but I and
hopefully more want not to be forced with that
code-contaminator, especially having a lot more vars)
Said that, I will not respond to comments about sharing globals
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Before responding (later) I have to add something additional first: About the OO comments (Note again for this 2nd main topic of this thread: the term "globals" - it is meant only as the vars of a module outside functions and not sharing vars throughout the app the term "global" - Python keyword for write access inside functions) Yes OO is a solution but Python invites also developers using functional or procedural style. I have used OO-terms to make it more visible to OO-developers or simply cause it is common knowlegde: I dont have and wanted not compare OO terminology with Python OO structure. When I have compared OO class members with Python globals or when I have used e.g. the term singleton than I have described the behaviour of a module from OO point of view and to show that OO languages need no"global"-keyword to fulfil its tasks, and to show that procedural style used in that manner is like nearby an OO-solution. So you dont need OO under all circumstances. There is a procedural/functional way too. Even other comparisons like type-safety is nothing else but to show that such languages need no "global" keyword. So, mainly with my comparison I tried to argue that there is no no need for a "global" keyword. Said that, I will not respond to comments about using OO or about comparisons made with other languages. (And by the way, OO in Python has something similiar (a.k.a "self"-keyword)) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Now I want reflecting the latest answers: I have the position of a high-level view (cause of lack of Python knowledge internals and compiler stuff, but also cause I think a language should be as far as possible user-friendly without knowing too much internals, and yes clearly cause of knowing OO-languages where I do not need such code-contamination) So, my high-level understanding of the "global"-keyword so far is: Give write access to a global var if this is set to this var inside a current code block. And this specific syntax construction is probably defined not cause it is really needed but cause it is assumed to help the developer avoiding mistakes, which I think is too much over-regulation. But from the answers given I maybe have to rethink about the global keyword. It seems to be an absolute need from low-level point of view - meaning the designer had no other choice as to invent the keyword "global": Two main reasons for the need of keyword "global" have been posted: Compiler - Python compiler or compiler at all cannot hide this from the developer? (It seems really a scripting problem. PHP has it, LUA has it vice versa, ...) Although I cannot really believe it, that technical reasons lead to this design. E.g recognizing if it is local or global: If this would be under the developer responsibility than this is simply achieved by giving well-written var names. And a compiler can surely recognize if a defined var xxx outside is not a var yyy inside a function. Or does anyone really name a global var xxx and a function var xxx? I am sure no one at all will do it. I dont want read such a code. Function calls (?) - I have to admit I did not really get the problematic from the sample provided by Chris Angelico. What I can see or mean to see is: it has nothing to do with global-keyword from the high level point of view: give write access, probably to the vars word and otherword. And yes, I see the vars independant. And cause you set no "global" they are simple local vars (readable+writeable) This is more about let me assume function call stack and closures things(?) which I think is handled automatically. But as said - here I cannot really respond. This have to be answered from more experienced users. My conclusion: -- My intention was to bring this into discussion and see what comes out and see what are the reasons for this keyword. I am not the user who can open the PEP, but maybe the community out decides to do so. But if this two problems really exists from low-level point of view, then ok, there is no other way than to use this keyword "global". I have not the experience to answer that. I can accept low-level problems if so. But then I ask you from high-level point of view (if my high level view is correct at all): Would you remove this keyword if it would be technically possible or is good for you from high level point of view to have a keyword "global"? My answer is clear: remove it. [The same e.g. with switch statement: add it] Then this is my question now! Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Before responding (later) I have to add something additional first: Cause of complaints and while still exists and again and again: When I mentioned maybe OO first than for also this reason cause Python is a powerful language and supports procedural and OO features and many more. And cause a Python module is conceptually a singleton I recognized this as another feature of this language, nearly similiar to an OO-construct. So it is Pyhton itself what brings me to OO thaughts. >From knowing e.g Java as OO language I had no need to set such a keyword "global" to get write access to class members. And now the main point: Cause all of the features and especially the singleton construct, I could not believe that Python does nearly all for me but forces me then to use such a "ugly" keyword "global" in comparison to other OO languages. So OO and other comparisons where only to demonstrate how it is in other languages (and maybe for OO developers to enter this talk more easily) but not written to give comments going aside from this topic. But I agree, I should have better never mentioned it. Please lay OO and sharing globals aside. It is really about procedural programming and "global"-keyword only. That said I will really give no longer any comments about this. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Now I want reflecting the latest answers: I think mostly everything is said. Maybe you skip directly to my conclusion on the end. -- Nevertheless I want grasp some points out where I think I could give a respective answer: "You are shifting declaration from one to another place" I would not say so: maybe it is a special prefix, but that you write once and not in every function (with additonal at least one "ugly" line of code). See no shifting here. And I think it cannot be duplicated elswhere cause you are in your single module's namespace. See no conflicts here. "You would create than all in one scope" (or "You would create namespace vulnerabilities") I would not say so: An enclosed code block has still its own scope. But if there is a global module var (e.g. recognized by a distinct name) inside this block than this var is from scope global. See no conflicts here. "Learn better Python" I am sure I am not alone (although the thread seems to isolate my opinion) And you maybe have recognized I have accepted that there is a need for "global". But admit I have to chew hard. See my conclusion. "Java have it ugly too" I would not say so: The examples providing with one var and one function does not reflecting real scenarios. Guess mostly classes have about 10 members and 10 functions. Each member about 10 chars long with 10 lines of code per function. seeing the global var inline is more readable than looking on the top of the function if the var is global or not + the addtional lines of code onyl cause making it global. I dislike @ too (also in Java). See the contamination in that point still in Python. -- Conclusion: --- I think we can agree - that there are (unfortunately) low-level issues that makes the removing of "global" impossible. !? - and there are also special (dynamic) programming constructs where a keyword "global" makes sense and should be available !? I think for a scripting language this would be a good solution: when used then the compiler should definitive look in the global namespace, otherwise the compiler has some "magic" to distinct global from local (probably simply by varname and scope of birth) And yes it is not that I want change Python mantras. But Python philospy is so far I know: "There's a most understandable way to do something and that is how it should be done" But that says not: Do not change things that makes the life easier for a developer (escpecially who wants to do simple or powerful procedural/functional scripting). So for me there are 6 things that is somehow "masochistic" in Python cause with all its powerful features it is remarkable that it is not addable. So, If I had the power I would include following features (especially as we talk about scripting and cause why not (?), it would not harm anyone who does not want to use it (!)): all is optional (so hardcore Pythonier would probabyl deny to make use of it): 1. optional keyword "global" (if technical possible) 2. switch statement 3. less restrictive indentation (as if it would really matter forgetting an empty space somewhere if something is intended more right than is the context clear for me) 4. universal scope 5. goto label 6- "include" script statement (extending namespace to another script, like PHP) I think this would make Python even more popular than it is now. Not to say: I would really love it then. Last but not least: Why does javascript, as sripting language too, need not such things like a keyword "global". It also very powerful language with dynamic binding, OO, ... This is my question now. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
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
Re: Python handles globals badly.
Some notes to the "global"-keyword and the other proposals. It has been proposed to have these six enhancements 1. optional keyword "global" 2. switch statement 3. less restrictive indentation 4. universal scope 5. goto label 6- "include" script statement with following proofs uncommented: 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, NO need for an explicit global. Optional ok. Another proof about identation: The parser can recognise identation with tabs and spaces. Otherwise semcicolons or brackets would be needed. It is correct that there have to be a decision for spaces or tabs. But sure not necessarily the exact same indentation to the right for each block. Jus more same inserter to the right and the context is clear. Another proof is Python itself (from Tutorial): "Python is an ... powerful programming language. It has ... and a simple but effective approach to object-oriented programming. Python's elegant syntax ... together with its interpreted nature, make it an ideal language for scripting ... . The proposals are all made for structual programming enhancements This is nothing else than having structural programming, functional programming and OO and many more features in parallel. Why that all? For the same reason: For an another type of programmers - or say: nothing more than even more flexibility. Read also here: https://en.wikipedia.org/wiki/History_of_Python Especially sections: "incfluences from other languages" But all proposals are more or less fully denied - for more or less no reasons. The last statement against the proposals: > "EVERYONE who suggests massive, sweeping changes says "hey, if you only > make these changes, Python will actually become popular". It's almost > mandatory." Additionally, that proofs: that this is not a single meaning. And also speaking from changes is wrong. Enhancements or extensions would be correct. There is the big question: Who is responding or has responded? Extreme Programmers, Python-Hardliner, Python-Evangelists, ... . Presumably no core Python Programmers (wrting compiler and standard library stuff) On Google groups you can currently read for this thread: 37 Authors. 152 posts. 443 views. That is not that much for views (probably mostly from the writer's itself) So, is this really the place where a PEP can be started? When has a proposal to be accepted? If ten-thousands say yes? Which ten-thousands? Who decides it? Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
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(): pass3 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. -- https://mail.python.org/mailman/listinfo/python-list
