scope of generators, class variables, resulting in global na

dontspamleo dontsendleospam at gmail.com
Sun Feb 28 06:45:38 EST 2010


> > ...and really means this...
> > class C:
> >   x = 1
> >   def f(self,y): return T.x + y
>
> I don't understand what T is. Did you mean C?

Yes, I meant C. Thanks.

>
> If so, you are wrong. self.x is not the same as <class>.x due to
> inheritance rules. Consider one example:
>
<example snipped see thread/>

Thanks for the nice example. Sorry for my loose language. By "really
means", what I really meant was that the most appropriate construct
should be the one referring to the class variable explicitly. I would
consider it inelegant (at least) to use an instance variable with the
same name as a class variable.

>
> > 1. Has this been discussed before?
>
> Yes.
>
> > 1. What would this suggestion break?
>
> Nearly all existing code using classes, which is nearly everything.

Is it that common to have code containing a class variable with the
same name as a global variable? Are there other use cases that would
break?

>
> > 2. What are the advantages of making the scope of class variables
> > different? Maybe is it just a historical trait?
>
> See the discussion in the PEP for introducing nested scopes in the first
> place:
>
> http://www.python.org/dev/peps/pep-0227/
>

Thanks. That is really useful. I just read the PEP. I find this
paragraph very helpful:

"An alternative would have been to allow name binding in class
    scope to behave exactly like name binding in function scope.  This
    rule would allow class attributes to be referenced either via
    attribute reference or simple name.  This option was ruled out
    because it would have been inconsistent with all other forms of
    class and instance attribute access, which always use attribute
    references.  Code that used simple names would have been obscure."

The point about all other access use cases requiring attribute
references is a really good one. If a language requires self.f() to
access the member f of class C, which happens to be a function, then
self.x or C.x should also be required to access attribute x. And no
one would be crazy enough to ask to have that fixed.

@Steven: Are there other snippets from the PEP you were pointing to
specifically?

Cheers,
Leo.




More information about the Python-list mailing list