Python handles globals badly.

[MRAB]

On 2015-09-12 06:22, Skybuck Flying wrote:
>
>
> "Michael Torrie"  wrote in message
> news:mailman.384.1442016089.8327.python-list at python.org...
>
> On 09/11/2015 03:50 PM, Skybuck Flying wrote:
>> Something which python does not seem to do currently ?!
>>
>> So that's weird.
>>
>> I will leave it at that for now.
>
> "
> Seems to me you have a completely mistaken understanding of how
> variables work in Python.  This is one of the reasons why I have said in
> the past, erroneously, that Python does not have variables.  It does of
> course but not in the same way as C or Pascal.  In those languages names
> are source-code abstractions only, and irrelevant to the compiler and
> machine code.  C and Pascal define variables as boxes that can be
> written to.  Not so in Python.
> "
>
> Well you basically said it yourself:
>
> " irrelevant to the compiler and machine code".
>
> That's kinda nice about a high level language.
>
> Programmer does not need to understand anything below the language.
>
> A python programmer shouldn't need to understand a damn thing to write:
>
> A  =  10
> A = A + 1
> print A
>
> However for sake of your discussion I will continue your arguments below,
> since I get the impression you guys are clueless how to change python
> implementation ;)
>
> "
> In Python most common objects are immutable. Meaning they can never
> change or be overwritten.  They are bound to names.  This binding is
> what makes names look like and act like traditional variables.
>
> The secret to understanding the global keyword is to understand how
> Python namespaces work.  The statement "a=5" does not assign a 5 to the
> box called "a."  Rather it binds the name "a" to the "5" object, which
> is immutable and called into existence by the interpreter
> implementation.  Subsequently "a=6" disconnects a from the 5 object,
> casting the 5 object loose to be reclaimed in some fashion that doesn't
> matter at this point.  "a" is then rebound to a new object, 6.
> "
>
> What happens for following code:
>
> A=1234567890111111
>
> Are you going to claim it's going to bind to all these numbers and then also
> multiple times ?
>
"all these numbers"? I see only one number there.

At runtime, it'll bind the name to the number, putting the pair into a
dict. (Actually, in a function, it can determine the names of all of
the local variables, so it uses 'slots' instead, as an optimisation.)

> Sounds a bit shady ?! ;)
>
> Perhaps python considers it a string ?
>
> Python applies math to strings ?
>
> Sounds a bit slow... therefore perhaps you're wrong...
>
Why would _he_ be wrong? _He_ never claimed any such thing!

> "
> When doing a look-up on a name, the interpreter first checks the local
> scope's dictionary and if it does not find the name there there, goes to
> the outer scope and so forth until you get to the module global
> namespace.  So we don't need any special keywords to do Pascal-style
> constants.  We just define them in the module and they work.  Usually we
> name them in all caps so we have a bit of a convention as to where they
> come from.  And yes we're talking about looking up strings in a
> dictionary here.
> "
>
> So big deal, solution is easy to see, invert interpreter logic:
>
> Everything declared is "not constant".
>
> Everything declared as "constant" suddenly becomes constant.
>
> And thus everything declared as not constant behaves the same way as
> "global", problem solved.
>
> "
> When binding a name to an object, the interpreter always binds a name in
> the local namespace, unless the global keyword has been used previously
> and then it goes right to the global namespace.  As has been said
> numerous times on this thread, how else would the interpreter do this?
> There simply isn't any other way that makes sense. Certainly you haven't
> made the case for it, seeing as you have some fundamental
> misunderstandings about variables in Python.
> "
>
> You didn't completely explain how the global namespace becomes writeable ?
> or re-bindeable ?
>
> (It seems not necessary to explain it you implement the constant idea, as
> explained above already).
>
> Do I have to assume that global namespace is "re-bindeable" = writeable ?
>
> "
> You keep saying things like "writing to a variable" or "declared
> variables" which just don't apply to Python because that's not how
> Python variables work.  It may appear this way on the surface, but the
> differences are subtle yet important.  Namespaces are written to, not
> variables, some objects can be mutated. Names are bound to objects, but
> variables are not declared, as a name can be bound to an object of any type.
> "
>
> Well again you didn't explain how using namespaces suddenly lead to
> "rewritable" and/or "rebinding"
>
Namespaces don't "become writeable".

The purpose of "global" is to tell the compiler that this name should
be bound in the global namespace, not the local namespace.

> if A is declared as global as follows:
>
> global A
>
> and then code is written as follows:
>
> A = 10
> A = 20
>
> def Test()
>      global A = 30
>      return
>
> How does this make A "rewriteable" ? Or "rebindable" to 30 ?
>
> "
> Namespaces are powerful constructs that give Python much of its dynamic
> nature and expressivity. Learn to use them!
> "
>
> I didn't learn anything from this posting, sorry ! ;)
>