[Samuele Pedroni]

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

The referenced URL http://www.python.org/doc/current/ref/customization.html appears irrelevant to me, so unsure what you're asking about. Perhaps http://www.python.org/doc/current/ref/attribute-access.html 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 explainable.

----- 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).

[Samuele Pedroni]

... The point is that jython implements the letter of the manual, and even extend the caching opt to some others __magic__ methods. I wanted to know the intended behaviour in order to fix that in jython.

You got that one right the first time: this requires BDFL pronouncement! As semantically significant optimizations (the only reason for caching __getattr__, e.g.) creep into the code but the docs lag behind, it gets more and more unclear what's mandatory behavior and what's implementation-defined. This came up a couple weeks ago again in the context of what, exactly, rich comparisons are supposed to do in all cases. After poking holes in everything Guido wrote, he turned it around and told me to write up what I think it should say (which I have yet to do, as it's time-consuming and it appears some of the current CPython behavior is at least partly accidental -- but unclear exactly which parts). So don't be surprised if the same trick gets played on you ...