[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