[Python-bugs-list] [ python-Bugs-532860 ] NameError assigning to class in a func
noreply@sourceforge.net
noreply@sourceforge.net
Fri, 19 Apr 2002 09:39:45 -0700
Bugs item #532860, was opened at 2002-03-21 01:27
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532860&group_id=5470
Category: Python Interpreter Core
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Jeremy Hylton (jhylton)
Summary: NameError assigning to class in a func
Initial Comment:
This fails with a NameError:
def f(x)
class Private:
x = x
return Private
f(17)
But this works:
def f(x):
y = x
class Private:
x = y
return Private
f(17)
But this fails:
def f(x):
y = x
class Private:
y = y
return Private
f(17)
See also the newsgroup thread:
http://groups.google.com/groups?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&threadm=Xns
(All tested on Python 2.2 on Win2k)
----------------------------------------------------------------------
>Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-19 16:39
Message:
Logged In: YES
user_id=31392
This is actually working as intended, although the reference
manual no longer describes this case at all. It has been a
long standing "feature" of Python that module and class
blocks use the LOAD_NAME opcode, which has weird scoping
rules.
The documentation should be updated to describe the cases in
which LOAD_NAME is used and its behavior. (It checks
locals, globals, builtins in that order, and never raises a
NameError unless the name isn't found in any of those
namespaces. In particular, an unbound local is simply
ignored.)
I don't actually know what these rules are used. Guido--
should we get rid of LOAD_NAME?
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532860&group_id=5470