[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).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4