Re: [Python-Dev] Dinamically set call method

References	(7 earlier) <8761eq424e.fsf@handshake.de> <mailman.15584.1415476169.18130.python-list@python.org> <cc7jtiFubltU1@mid.individual.net> <CALwzidnE9ZeHV6nM74hKX58LhZ0ova5qB60-eWbw2gLTtk+O3Q@mail.gmail.com> <CANXBEFqot+KNkhVt210JApbJ7nnENHVszHS-R=J6k222t-3A9w@mail.gmail.com>
From	Ian Kelly <ian.g.kelly@gmail.com>
Date	2014-11-12 11:58 -0700
Subject	Re: [Python-Dev] Dinamically set __call__ method
Newsgroups	comp.lang.python
Message-ID	<mailman.15735.1415818783.18130.python-list@python.org> (permalink)

Show all headers | View raw

On Wed, Nov 12, 2014 at 8:33 AM, Fabio Zadrozny <fabiofz@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.

Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [Python-Dev] Dinamically set __call__ method Ethan Furman <ethan@stoneleaf.us> - 2014-11-04 11:12 -0800
  Re: [Python-Dev] Dinamically set __call__ method John Ladasky <john_ladasky@sbcglobal.net> - 2014-11-06 12:21 -0800
    Re: [Python-Dev] Dinamically set __call__ method dieter <dieter@handshake.de> - 2014-11-07 07:59 +0100
    Re: [Python-Dev] Dinamically set __call__ method Ethan Furman <ethan@stoneleaf.us> - 2014-11-07 04:58 -0800
    Re: [Python-Dev] Dinamically set __call__ method dieter <dieter@handshake.de> - 2014-11-08 07:50 +0100
    Re: [Python-Dev] Dinamically set __call__ method Ethan Furman <ethan@stoneleaf.us> - 2014-11-08 11:49 -0800
      Re: [Python-Dev] Dinamically set __call__ method Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-11-09 11:31 +1300
        Re: [Python-Dev] Dinamically set __call__ method Ethan Furman <ethan@stoneleaf.us> - 2014-11-08 19:27 -0800
          Re: [Python-Dev] Dinamically set __call__ method Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-11-10 00:38 +1300
            Re: [Python-Dev] Dinamically set __call__ method Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-10 00:14 +1100
            Re: [Python-Dev] Dinamically set __call__ method Ethan Furman <ethan@stoneleaf.us> - 2014-11-09 12:16 -0800
        Re: [Python-Dev] Dinamically set __call__ method Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-11 00:43 -0700
        Re: [Python-Dev] Dinamically set __call__ method Fabio Zadrozny <fabiofz@gmail.com> - 2014-11-12 13:33 -0200
          Re: [Python-Dev] Dinamically set __call__ method Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-11-13 17:20 +1300
            Re: [Python-Dev] Dinamically set __call__ method Fabio Zadrozny <fabiofz@gmail.com> - 2014-11-13 11:38 -0200
        Re: [Python-Dev] Dinamically set __call__ method Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-12 11:58 -0700

csiph-web