scope of generators, class variables, resulting in global na
dontsendleospam at gmail.com
Sun Feb 28 12:45:38 CET 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?
> > 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
> > 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
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
More information about the Python-list