In <mailman.509.1251373513.2854.python-l...@python.org> Jean-Michel Pichavant <jeanmic...@sequans.com> writes:
>kj wrote: >> I think I understand the answers well enough. What I *really* >> don't understand is why this particular "feature" of Python (i.e. >> that functions defined within a class statement are forbidden from >> "seeing" other identifiers defined within the class statement) is >> generally considered to be perfectly OK. IMO it's a bizarre, >> inexplicable blindspot (which, among other things, gives rise to >> a certain worry about what other similar craziness lurks under >> Python's image of rationality). I have never seen even a half-hearted >> justification, from a language design point of view, for why this >> particular "feature" is worth having. Maybe some day the BDFL will >> deign to give one. >> >> kynn >> >I think I got your point. >I guess many people may not be receptive to your question, cause guess >what, we're all python fans :o) >in foo.py: >a = 5 >b = a # works fine >class A: > c = 5 > d = c # broken > d = A.c # broken either > > def foo(self): > e = 5 > f = e #works fine >We should all acknowledge that any newcomer to python will not expect >such behavior. There are plenty of good answers to that thread >explaining why the fact that classes are not scopes is much better. >Still this design fails at one point : insight. >It may be solved by creating the class upon the "class" statement. If >the class A object is created, then c is added as a property of that >object, there's no problem accession one object property with A.c. Thanks! I was beginning to think I'd gone crazy. kynn -- http://mail.python.org/mailman/listinfo/python-list