Python handles globals badly.

Mark Lawrence breamoreboy at yahoo.co.uk
Sat Sep 12 05:01:24 CEST 2015


On 12/09/2015 01:01, Michael Torrie wrote:
> 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.
>
> 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.
>
> 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.
>
> 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 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.
>
> Namespaces are powerful constructs that give Python much of its dynamic
> nature and expressivity. Learn to use them!
>

My favourite analogy for Python names, the sticky note, here 
https://mail.python.org/pipermail/tutor/2006-October/049767.html

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence



More information about the Python-list mailing list