Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!nzpost1.xs4all.net!not-for-mail
To: python-list@python.org
From: Mark Lawrence <breamoreboy@yahoo.co.uk>
Subject: Re: Python handles globals badly.
Date: Sat, 12 Sep 2015 04:01:24 +0100
References: <c3363$547e74fe$5419aafe$24179@news.ziggo.nl> <14afe27e-0bd5-410f-8e64-0f31d496ebf2@googlegroups.com> <b695e$55f34cad$d47876e2$41259@news.ziggo.nl> <55F36B4C.9020007@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
In-Reply-To: <55F36B4C.9020007@gmail.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.395.1442027105.8327.python-list@python.org>
Lines: 65
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:96387

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