Need help with Python scoping rules
no.email at please.post
Thu Aug 27 14:09:44 CEST 2009
In <mailman.509.1251373513.2854.python-list at python.org> Jean-Michel Pichavant <jeanmichel at sequans.com> writes:
>> 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.
>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)
>a = 5
>b = a # works fine
> 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.
More information about the Python-list