Home Original page

[Python-Dev] [Python-3000] Code freeze?

Nick Coghlan ncoghlan at gmail.com
Fri Feb 29 15:30:39 CET 2008 
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 at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org
More information about the Python-Dev mailing list