Path: csiph.com!usenet.pasdenom.info!news.etla.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Fri, 5 Dec 2014 10:53:09 +0800
From: "shiyao.ma" <i@introo.me>
To: LJ <luisjosenovoa@gmail.com>, python-list@python.org
Subject: Re: About Modifying Globals
References: <aa74bd64-0e11-492d-ae2a-4b032a0408f9@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <aa74bd64-0e11-492d-ae2a-4b032a0408f9@googlegroups.com>
User-Agent: All mail clients suck. This one just sucks less.
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.16604.1417748003.18130.python-list@python.org>
Lines: 45
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:81970

On 12/04, LJ wrote:
> Hi All,
>
> I have a quick question regarding the modification of global variables within functions. To illustrate, consider the following toy example:
>
> a={"1": set()}
> b=9
>
> def gt(l):
>    a["1"] = a["1"] | set([l])
>
> When calling this last function and checking the a dictionary, I get:
>
> >>> gt(5)
> >>> a
> {"1": set([5])}
>
>
> The set in the dictionary was modified. The question is, why isn't it necessary to declare a as global within the gt function, as apposed to a case like
>
> def gt2(l):
>    b=b+l
>
> where I need to declare b as global within the function to avoid:
>
> UnboundLocalError: local variable 'b' referenced before assignment.

Well. To understand the difference, one first has to know the mechanism of CPython.
When you have a script, CPython will first parse it, and then generate bytecode representation, and then finally execute it.
If you take a look at the bytecode of both your source code, you will notice, that.

In the first snippet, there is something like LOAD_NAME, which loads the global name a.
However, in the second snippet, there would be a LOAD_FAST, which loads the local name b (which is, technically speaking, stored in the PyFrameObj).

The reason Python treats it differently, is, IIUC, for better semantic meaning, and also, for huge performance improvement.


Hope that explains.


Regards.

-- 
Shiyao Ma
http://introo.me