Christian Heimes wrote:
Is this documented somewhere? The docs say "See the :meth:`__getattribute__` method below for a way to actually get total control over attribute access.".
I just checked, and the restriction is now documented in the development docs in the section on special methods at [1]. It was backported from the Py3k docs and isn't part of the docs for 2.5 or earlier versions. The gist is that special methods *must* be defined directly on a new-style class in order for the interpreter to reliably access them, but defining them on a new-style instance *may* still affect the interpreter's behaviour in some cases (but won't necessarily do so). In composing this response, I also realised why the new tempfile tests worked for me before I checked them in: I was testing it on the trunk, where _TemporaryFileWrapper is a classic class. Special method lookup on classic classes doesn't include the 'direct-to-type' optimisation, so those tests work with the tempfile module as written on 2.x. Unfortunately, proxies like _TemporaryFileWrapper that rely on __getattr__ to provide special methods simply won't work properly when implemented as new-style classes - for that, they need to spell out the overridden special methods the way SpooledTemporaryFile does. I think we may need a -3 warning that detects situations where "__*__" attributes are retrieved via a __getattr__ implementation on a classic class - classes being used that way have a very high chance of breaking when ported to 3.0 and I can't see any possible way for 2to3 to detect them. Cheers, Nick. [1] http://docs.python.org/dev/reference/datamodel.html#special-method-names -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org