[Python-Dev] What should changing/setting __getattr__ (and similars) after classdef time do ?

Tim Peters tim.one@home.com
Sat, 2 Jun 2001 18:57:57 -0400

[Samuele Pedroni]
> Is this a case that only the BDFL could know and pronounce on ...
> or I'm missing somenthing ...

The referenced URL


appears irrelevant to me, so unsure what you're asking about.  Perhaps


was intended?  If so, the

    these methods are cached in the class object at class
    definition time; therefore, they cannot be changed after
    the class definition is executed.

there doesn't mean exactly what it says:  it's trying to say that the
__XXXattr__ methods *inherited from base classes* (if any) are cached in the
class object at class definition time, so that changing them in the base
classes later has no effect on the derived class.  It should be clearer.

A direct class setattr can still change them; indirect assignment via
class.__dict__ is ineffective for the __dict__, __bases__, __name__,
__getattr__, _setattr__ and __delattr__ class attributes (yes, you'll create
a dict entry then, but class getattr doesn't look in the dict to get the
value of these specific keys).

Didn't understand the program snippet.

Much of this is due to hoary optimizations and I agree is ill-documented.  I
hope Guido's current rework of all this stuff will leave the endcases more

> ----- Original Message -----
> From: Samuele Pedroni <pedroni@inf.ethz.ch>
> To: <python-dev@python.org>
> Sent: Friday, June 01, 2001 2:49 PM
> Subject: [Python-Dev] __xxxattr__ caching semantic
> Hi.
> What is the intendend semantic wrt to __xxxattr__ caching:
> class X:
>   pass
> def cga(self,name):
>   print name
> def iga(name):
>   print name
> x=X()
> x.__dict__['__getattr__'] = iga # 1.
> x.__getattr__ = iga # 2.
> X.__dict__['__getattr__'] = cga # 3.
> X.__getattr__ = cga # 4.
> x.a
> for the manual
> http://www.python.org/doc/current/ref/customization.html
> with all the variants x.a should fail, they should have
> no effect. In practice 4. work.
> Is that an implementation manual mismatch, is this indented, is there
> code around using 4. ?
> I'm asking this because jython has differences/bugs in this respect?
> I imagine that 1.-4. should work for all other __magic__ methods
> (this should be fixed in jython for some methods),
> OTOH jython has such a restriction on __del__ too, and this one cannot
> be removed (is not simply a matter of caching/non caching).