Need help with Python scoping rules

kj 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:

>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




More information about the Python-list mailing list