[Python-Dev] special method lookup: how much do we care?

Nick Coghlan ncoghlan at gmail.com
Sun May 10 23:51:32 CEST 2009


Benjamin Peterson wrote:
> A while ago, Guido declared that all special method lookups on
> new-style classes bypass __getattr__ and __getattribute__. This almost
> completely consistent now, and I've been working on patching up a few
> incorrect cases. I've know hit __enter__ and __exit__. The compiler
> generates LOAD_ATTR instructions for these, so it uses the normal
> lookup. The only way I can see to fix this is add a new opcode which
> uses _PyObject_LookupSpecial, but I don't think we really care this
> much. Opinions?

As Georg pointed out, the expectation was that we would eventually add a
SETUP_WITH opcode that used the special method lookup (and hopefully
speed with statements up to a point where they're competitive with
writing out the associated try statement directly). The current code is
the way it is because there is no "LOAD_SPECIAL" opcode and adding type
dereferencing logic to the expansion would have been difficult without a
custom opcode.

For other special methods that are looked up from Python code, the
closest we can ever get is to bypass the instance (i.e. using
"type(obj).__method__(obj, *args)") to avoid metaclass confusion. The
type slots are even *more* special than that because they bypass
__getattribute__ and __getattr__ even on the metaclass for speed reasons.

There's a reason the docs already say that for a guaranteed override you
*must* actually define the special method on the class rather than
merely making it accessible via __getattr__ or even __getattribute__.

The PyPy guys are right to think that some developer somewhere is going
to rely on these implementation details in CPython at some point.
However lots of developers rely on CPython ref counting as well, no
matter how many times they're told not to do that if they want to
support alternative interpreters.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


More information about the Python-Dev mailing list