[issue9226] erroneous behavior when creating classes inside a closure

[Irit Katriel]

Irit Katriel  added the comment:

Reproduced on 3.11.

--
nosy: +iritkatriel
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.6, Python 2.7, Python 
3.1, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Tal Einat]

Tal Einat  added the comment:

See additional discussion in the duplicate issue19979.

--
nosy: +taleinat

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Nick Coghlan]

Changes by Nick Coghlan ncogh...@gmail.com:


--
nosy: +ncoghlan

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Guido van Rossum]

Guido van Rossum gu...@python.org added the comment:

Hm. This seems an old bug, probably introduced when closures where first 
introduced (2.1 ISTR, by Jeremy Hylton).

Class scopes *do* behave differently from function scopes; outside a nested 
function, this should work:

x = 1
class C(object):
  x = x
assert X.x == 1

And I think it should work that way inside a function too.

So IMO the bug is that in classes Test and Test3, the x defined in the function 
scope is not used.  Test2 shows that normally, the x defined in the inner scope 
is accessed.

So, while for *function scopes* the rules are if it is assigned anywhere in 
the function, every reference to it references the local version, for *class 
scopes* (outsided methods) the lookup rules are meant to be dynamic, meaning 
if it isn't defined locally yet at the point of reference, use the next outer 
definition.

I haven't reviewed the patches.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Guido van Rossum]

Guido van Rossum gu...@python.org added the comment:

I meant, of course,

assert C.x == 1

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Terry J. Reedy]

Terry J. Reedy tjre...@udel.edu added the comment:

Guido clarified:
 Class scopes *do* behave differently from function scopes;
 outside a nested function, this should work:
 x = 1
 class C(object):
   x = x
 assert C.x == 1
 And I think it should work that way inside a function too.

I take that to mean that

x = 0
def f()
  x = 1
  class C(object):
x = x
  assert C.x == 1
f()

should work, meaning that C.x==0 and UnboundLocalError are both wrong.

That would mean to me that in The class’s suite is then executed in a new 
execution frame (see section Naming and binding), using a newly created local 
namespace and the original global namespace. the phrase the original global 
namespace should be changed to the surrounding namespaces.

I also think this from Guido

So, while for *function scopes* the rules are if it is assigned anywhere in 
the function, every reference to it references the local version, for *class 
scopes* (outsided methods) the lookup rules are meant to be dynamic, meaning 
if it isn't defined locally yet at the point of reference, use the next outer 
definition.

should somehow also be clearer, probably also in the class page, so that people 
will neither expect an UnboundLocalError.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Guido van Rossum]

Guido van Rossum gu...@python.org added the comment:

On Sat, Jul 24, 2010 at 3:21 PM, Terry J. Reedy rep...@bugs.python.org wrote:

 Terry J. Reedy tjre...@udel.edu added the comment:

 Guido clarified:
 Class scopes *do* behave differently from function scopes;
 outside a nested function, this should work:
 x = 1
 class C(object):
   x = x
 assert C.x == 1
 And I think it should work that way inside a function too.

 I take that to mean that

 x = 0
 def f()
  x = 1
  class C(object):
    x = x
  assert C.x == 1
 f()

 should work, meaning that C.x==0 and UnboundLocalError are both wrong.

Indeed.

 That would mean to me that in The class’s suite is then executed in a new 
 execution frame (see section Naming and binding), using a newly created local 
 namespace and the original global namespace. the phrase the original global 
 namespace should be changed to the surrounding namespaces.

Those words sound like they were never revised since I wrote them for
Python 0.9.8 or so...

 I also think this from Guido

 So, while for *function scopes* the rules are if it is assigned anywhere in 
 the function, every reference to it references the local version, for *class 
 scopes* (outsided methods) the lookup rules are meant to be dynamic, meaning 
 if it isn't defined locally yet at the point of reference, use the next 
 outer definition.

 should somehow also be clearer, probably also in the class page, so that 
 people will neither expect an UnboundLocalError.

FWIW, unless something drastically changed recently, the language
reference is likely out of date in many areas. I would love it if a
team of anal retentive freaks started going through it with a fine
comb so as to make it describe the state of the implementation(s) more
completely.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Terry J. Reedy]

Terry J. Reedy tjre...@udel.edu added the comment:

Chris, when posting something like this, *please* include the output. I had to 
insert ()s to run this with 3.1. I will upload the py3 version as test3.py. Is 
your output the same as mine?

x: success
Test.x: error
Test2.y: success
Test3.x: error
Test3.y: error
Test4.x: success

There is an obvious inconsistency between Test2 and Test/Test3. This shows up 
also in the dis.dis(test) output. So there is definitely a bug.

To me, the Test2 result is the error. I base this on 7.7 Class Definitions: 
The class’s suite is then executed in a new execution frame (see section 
Naming and binding), using a newly created local namespace and the original 
global namespace. I interpret this to mean that intermediate namespaces are 
not used (as was the case before 2.2). Indeed, this sentence is unchanged from 
the 2.1 doc (and before).
http://docs.python.org/release/2.1/ref/class.html

Of course, the intent could have changed without changing the wording, by 
reference to the Naming and Binding section, but then this sentence really 
should be changed too.

The current Naming and Binding section includes:

A scope defines the visibility of a name within a block. If a local variable 
is defined in a block, its scope includes that block. If the definition occurs 
in a function block, the scope extends to any blocks contained within the 
defining one, unless a contained block introduces a different binding for the 
name. The scope of names defined in a class block is limited to the class 
block; it does not extend to the code blocks of methods.

So class blocks are an exception in propagating down, and I thought they were 
also an exception for propagating into, for the reason stated above. 

It is possible that this is an undefined corner of the language. Certainly, the 
compiler is confused as it treats one nested class (Test2) as a closure and the 
other three nested classes as not.

Since the name and binding design is Guido's and central to Python's operation, 
I personally would not touch it without his input. Hence I have added him as 
nosy and second the idea of pydev discussion.

--
nosy: +gvanrossum, tjreedy
Added file: http://bugs.python.org/file18164/test3.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Chris Monsanto]

New submission from Chris Monsanto ch...@monsan.to:

I have a function whose closure contains a local variable that shadows a global 
variable (lets call it x). If I create a class as follows: 

class Test(object): x = x

Test.x will contain the value of the global x, not the local x. This ONLY 
happens when the names are the same, and it only happens in the class body; 
i.e., class Test(object): y = x and class Test(object): pass; Test.x = x 
work fine.

However, if there is an assignment x = x AND you make other assignments, such 
as y = x, in the body, the other variables will have the wrong value too.

Test case attached. Problem noticed on Python 2.6.2 on Windows and 2.6.5 on 
Linux.

--
files: test.py
messages: 110037
nosy: monsanto
priority: normal
severity: normal
status: open
title: erroneous behavior when creating classes inside a closure
versions: Python 2.6
Added file: http://bugs.python.org/file17950/test.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Chris Monsanto]

Chris Monsanto ch...@monsan.to added the comment:

A friend confirmed that this was the case on 3.1.2 as well.

--
versions: +3rd party -Python 2.6

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Chris Monsanto]

Changes by Chris Monsanto ch...@monsan.to:


--
versions: +Python 2.6, Python 3.1 -3rd party

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Mark Dickinson]

Changes by Mark Dickinson dicki...@gmail.com:


--
components: +Interpreter Core
stage:  - needs patch
type:  - behavior
versions: +Python 2.7, Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Benjamin Peterson]

Benjamin Peterson benja...@python.org added the comment:

I'm not sure what I correct behavior is in this case. Consider the function 
equivalent:

x = 3
def f(x):
def m():
x = x
print x
m()
f(4)

which gives:

Traceback (most recent call last):
  File x.py, line 7, in module
f(4)
  File x.py, line 6, in f
m()
  File x.py, line 4, in m
x = x
UnboundLocalError: local variable 'x' referenced before assignment

The class example works because name namespaces are unoptimized, so failing to 
find a binding in the local (class) namepsace, Python looks at the globals and 
finds the global definition.

--
nosy: +benjamin.peterson

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Mark Dickinson]

Mark Dickinson dicki...@gmail.com added the comment:

I don't see anything in

http://docs.python.org/reference/executionmodel.html#naming-and-binding

to suggest that the class should behave differently from a nested function 
here;  that is, I'd expect UnboundLocalError.

--
nosy: +mark.dickinson

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Mark Dickinson]

Mark Dickinson dicki...@gmail.com added the comment:

Jython 2.5.1 gives the same results as Python:

newton:~ dickinsm$ cat test.py
x = error

def test(x):
class Test(object):
x = x
print(x: , x)
print(Test.x: , Test.x)

test(success)
newton:~ dickinsm$ jython2.5.1/jython test.py
('x: ', 'success')
('Test.x: ', 'error')

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[R. David Murray]

R. David Murray rdmur...@bitdance.com added the comment:

I agree with Mark, I'd expect an UnboundLocalError.   I remembered this thread 
on Python-dev that may or may not be relevant, but is certainly analogous:

http://www.mail-archive.com/python-...@python.org/msg37576.html

--
nosy: +r.david.murray

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Benjamin Peterson]

Benjamin Peterson benja...@python.org added the comment:

Here's a patch. It raises a NameError in that case.

--
keywords: +patch
Added file: http://bugs.python.org/file17953/obscure_corner_cases.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Mark Dickinson]

Mark Dickinson dicki...@gmail.com added the comment:

I think it would be worth bringing this up on python-dev, especially since it 
affects alternative Python implementations.

It would also be good to have a documentation fix to the reference manual that 
clearly explains whatever behaviour is decided on;  it's not at all clear (to 
me, anyway), how to extract this information from the docs.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Éric Araujo]

Changes by Éric Araujo mer...@netwok.org:


--
nosy: +merwok

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Benjamin Peterson]

Changes by Benjamin Peterson benja...@python.org:


Added file: http://bugs.python.org/file17954/obscure_corner_cases2.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9226] erroneous behavior when creating classes inside a closure

[Eric Smith]

Changes by Eric Smith e...@trueblade.com:


--
nosy: +eric.smith

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9226
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com