[Python-ideas] Eliminating special method lookup (was Re: Missing Core Feature: + - * / | & do not call __getattr__)

Nick Coghlan ncoghlan at gmail.com
Sun Dec 6 07:58:51 EST 2015


On 6 December 2015 at 11:56, Andrew Barnert via Python-ideas
<python-ideas at python.org> wrote:
> On Dec 5, 2015, at 09:30, Guido van Rossum <guido at python.org> wrote:
>> (However, giving the metaclass more control is not unreasonable. There also seems to be some interesting behavior here related to slots.)
>
> I'm not sure what you're suggesting here. That implementations can let a metaclass __getattribute__ hook special method lookup, but some implementations (including CPython 3.6) won't do so?

Ronald Oussoren has elaborated on that aspect of the problem in his
__getdescriptor__ PEP: https://www.python.org/dev/peps/pep-0447/

The main reason it's separate from __getattribute__ is that this is
necessary to avoid changing the semantics of super.__getattribute__,
but it's also the case that things would otherwise get quite confusing
with object.__getattribute__ and super.__getattribute__ potentially
calling type.__getattribute__, which then has the potential for
strange consequences when you consider that "type" is itself an
instance of "type".

My recollection of the previous round of discussions on that PEP is
that we're actually pretty happy with the design - it's now dependent
on someone with the roundtuits to update the reference implementation
to match the current PEP text and the head of the current development
branch.

Regards,
Nick.

P.S. Now that I've realised PEP 447 is relevant to the current
discussion, I've also realised that providing a base case in
type.__getattribute__ that terminates the metaclass lookup chain for
attributes is likely sufficient explanation for why this works the way
it does now - if it didn't, type being its own metaclass would trigger
a recursion error. PEP 447 extends the chain one step further (to the
metaclass) by introducing a new magic method, but *that* method in
turn still can't be altered the metaclass of the metaclass.

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


More information about the Python-ideas mailing list