2011/8/15 Vitja Makarov <vitja.maka...@gmail.com>: > 2011/8/15 Stefan Behnel <stefan...@behnel.de>: >> Vitja Makarov, 15.08.2011 11:55: >>> >>> 2011/8/15 Stefan Behnel: >>>> >>>> Stefan Behnel, 15.08.2011 11:34: >>>>> >>>>> at least to me, the most surprising thing is this: >>>>> >>>>> >>> A = 1 >>>>> >>> def foo(x): >>>>> ... A = x >>>>> ... class X: >>>>> ... a = A >>>>> ... return X >>>>> ... >>>>> >>> foo(2).a >>>>> 2 >>>>> >>> def foo(x): >>>>> ... A = x >>>>> ... class X: >>>>> ... A = A >>>>> ... return X >>>>> ... >>>>> >>> foo(2).A >>>>> 1 >>>>> >>>>> That looks pretty sick, but I would guess that the 'reasoning' behind >>>>> this >>>>> is that the second case contains an assignment to A inside of the class >>>>> namespace, and assignments make a variable local to a scope, in this >>>>> case, >>>>> the function scope. >>>> >>>> Argh, sorry, I interpreted the results the wrong way around. >> >> ... or rather used the right reasoning to draw the wrong conclusion. ;) >> >> Ok, so there's an assignment in the second case, which makes A local to the >> class scope, thus overriding the definition in the function scope. Now, when >> it's being looked up at runtime, it's not in the class locals, so the lookup >> falls through to the globals. In the first case, it's not defined in the >> class scope at all, so it's taken from the surrounding function scope >> directly (and statically). >> >> >>> I've tried emulate this behaviour in cython here: >>> >>> >>> https://github.com/vitek/cython/commit/26ec702fd93fb6dc2109a501b52130e5f775c793 >> >> My feeling is that it should rather be a matter of static analysis to figure >> out which is meant, although I think your change mimics what CPython does. I >> guess this would fix #671, right? >> > > Yes. And I use CF info in my commit. > >> >>> Actually I think this is made to support assignments like A = A in class >>> scope. >> >> This behaviour wouldn't be strictly required for that goal. My guess is that >> it was just simpler to implement in CPython, because it has less special >> cases. Having to look up a name in a series of outer scopes in the case that >> it happens not to be defined in a class scope yet (although it is known to >> get defined therein at some point), or even remembering the right scope >> where it needs to get looked up, is trickier than just falling through to >> the globals. >> > > It's documented here: > > http://docs.python.org/reference/executionmodel.html#interaction-with-dynamic-features > > """ > Names may be resolved in the local and global namespaces of the > caller. Free variables are not resolved in the nearest enclosing > namespace, but in the global namespace. > """ > >
I think I'm done with the issue and if you don't mind I'll push that. https://github.com/vitek/cython/commit/b4a0493efbae68b30d54f0c58311c71465d57d43 -- vitja. _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
