Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!feeder.news-service.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
DomainKey-Signature: a=rsa-sha1; c=nofws; d=rebertia.com; s=google; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=KzFEpVUxmj4P8Zyh9rxrSkPKm3YK9PvId/1HMKjE+RJQQ20RqLd/+QPIT2stO8Z4+c 6mJ3zKUm/qp/hh68rJQNUjmkB/4MsDByRIGn9JtjWSJ85mqjVgMW3ZULrAwgj7CLEsMW ilOlsTg6mkbdtBmqvieX54KlY50Qpe4o6ATaQ=
MIME-Version: 1.0
Sender: chris@rebertia.com
In-Reply-To: <BANLkTinv1UocRuHm1LT6AbP+0vCvLHyk4Q@mail.gmail.com>
References: <BANLkTinv1UocRuHm1LT6AbP+0vCvLHyk4Q@mail.gmail.com>
Date: Sun, 17 Apr 2011 12:56:23 -0700
Subject: Re: Namespaces in functions vs classes
From: Chris Rebert <clp2@rebertia.com>
To: Gerald Britton <gerald.britton@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "python-list \(General\)" <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.473.1303070184.9059.python-list@python.org>
Lines: 92
NNTP-Posting-Host: 82.94.164.166
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:3424

On Sun, Apr 17, 2011 at 12:30 PM, Gerald Britton
<gerald.britton@gmail.com> wrote:
> I apologize if this has been answered before or if it is easy to find
> in the docs. (I couldn't find it but might have missed it)
>
> I'm trying to understand the differences between namespaces in class
> definitions vs. function definitions. =C2=A0Consider this function:
>
>>>> def a():
> ... =C2=A0 =C2=A0 foo =3D 'foo'
> ... =C2=A0 =C2=A0 def g(x):
> ... =C2=A0 =C2=A0 =C2=A0 =C2=A0 return foo
> ... =C2=A0 =C2=A0 print g(1)
> ...
>>>> a()
> foo
>>>>
>
> Now, I replace the first "def" with "class":
>
>>>> class a():
> ... =C2=A0 =C2=A0 foo =3D 'foo'
> ... =C2=A0 =C2=A0 def g(x):
> ... =C2=A0 =C2=A0 =C2=A0 =C2=A0 return foo
> ... =C2=A0 =C2=A0 print g(1)
> ...
> Traceback (most recent call last):
> =C2=A0File "<stdin>", line 1, in <module>
> =C2=A0File "<stdin>", line 5, in a
> =C2=A0File "<stdin>", line 4, in g
> NameError: global name 'foo' is not defined
>
> So, the variable "foo" is not available inside the function inside
> class as it is inside the (inner) function. =C2=A0I figured this was just
> because the class was still being defined, so I tried this:
>
>>>> class a():
> ... =C2=A0 =C2=A0 foo =3D 'foo'
> ... =C2=A0 =C2=A0 def g(x):
> ... =C2=A0 =C2=A0 =C2=A0 =C2=A0 return foo
> ...
>>>> x =3D a()
>>>> x.g()
> Traceback (most recent call last):
> =C2=A0File "<stdin>", line 1, in <module>
> =C2=A0File "<stdin>", line 4, in g
> NameError: global name 'foo' is not defined
>>>>
>
> which still fails. =C2=A0I had expected that "foo" would be available
> within the namespace of the object instance. =C2=A0I was wrong. =C2=A0For=
 my
> final attempt, I add the prefix "a." to my use of "foo"
>
>>>> class a():
> ... =C2=A0 =C2=A0 foo =3D 'foo'
> ... =C2=A0 =C2=A0 def g(x):
> ... =C2=A0 =C2=A0 =C2=A0 =C2=A0 return a.foo
> ...
>>>> x =3D a()
>>>> x.g()
> 'foo'
>
> So, this works and I can use it. =C2=A0However, =C2=A0I would like a deep=
er
> understanding of why I cannot use "foo" as an unqualified variable
> inside the method in the class. =C2=A0If Python allowed such a thing, wha=
t
> problems would that cause?

Class-level scope is simply never consulted when looking up
unqualified names in methods. When looking up such name from within a
method, the following scopes are consulted, in order (ignoring some
subtleties):
1. Local variables
2. Variables in nested functions
3. Global variables
4. Built-ins

For "workarounds" for this, see:
http://mail.python.org/pipermail/python-list/2009-December/1228354.html

As to why Python works this way, I'm not sure. However, one could
cogently argue that this requires you to be more explicit about what
the scope is of the name you're referring to; which set of semantics
you desire in the face of inheritance, monkey-patching, and instance
variable shadowing makes this trickier than you might otherwise think.

Cheers,
Chris
--
http://blog.rebertia.com