On Wed, Nov 12, 2014 at 8:33 AM, Fabio Zadrozny <fabi...@gmail.com> wrote: > As a reference, I recently found a blog post related to that: > http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/ (the Slots > part comments on that). > > It does seem a bit counter-intuitive that this happens the way it does > though, so, can someone from python-dev give some background of why that's > the way it is? i.e.: instead of the approach which would seem simpler which > would do getattr(a, '__call__') instead of > type(a).__dict__['__call__'].__get__(a, type(a)) -- it seems to me it's > mostly because of historical reasons, but I'm really curious why is it so > (and if maybe it's something which python-dev would consider worth changing > in the future -- not sure how much could break because of that though).
I'm not "someone from python-dev", but I think it's done to keep the look-up logic predictable and avoid having to call __getattribute__ and __getattr__ when looking up magic methods. For at least __getattribute__ and __getattr__ themselves we *can't* invoke those methods while trying to look them up, so there's a case to be made for consistency in that this way we don't have to remember which magic methods use __getattribute__ and which ones don't. Performance is also part of it, since these methods tend to be invoked frequently. -- https://mail.python.org/mailman/listinfo/python-list
