This is a language limitation.
That was my understanding as well, but I think it is a pity to have that limitation. Don't you think that the same improvement that was done for method nested scope could be done as well for nested class?
I can easily fix my current issue by doing the binding after the class declaration.
My concern is more about the lack of symmetry of that approach; meaning that if both classes are in the global scope, one can access the others, whereas if they are in the body of another class they cannot.
This is OK:
class A(object):
pass
class B(object):
foo=A
I have to add the binding after the declaration in the case of nested:
class C(object):
class A(object):
pass
class B(object):
foo=None
B.foo = A
That extra step is a little bit painful and should not be necessary for my point of view.
py3k?
nonlocal doesn't adress this issue an I doubt python 3.0 fix it at all.
You have the same problem with generator expressions, which bind lately
outer
loop variables :
Good to know, I was not aware of that.
Thanks,
Benoit
This is because nested scope is implemented for python function only since
2.3
allow late binding of free variables. the scope in class statment is not a
closure, so there is only two possible scope in it : local and global.
2.3
allow late binding of free variables. the scope in class statment is not a
closure, so there is only two possible scope in it : local and global.
I can easily fix my current issue by doing the binding after the class declaration.
My concern is more about the lack of symmetry of that approach; meaning that if both classes are in the global scope, one can access the others, whereas if they are in the body of another class they cannot.
This is OK:
class A(object):
pass
class B(object):
foo=A
I have to add the binding after the declaration in the case of nested:
class C(object):
class A(object):
pass
class B(object):
foo=None
B.foo = A
That extra step is a little bit painful and should not be necessary for my point of view.
I'm wondering as well if the new nonlocal statement will fix that in
You have the same problem with generator expressions, which bind lately
outer
loop variables :
Thanks,
Benoit