Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.012 X-Spam-Evidence: '*H*': 0.98; '*S*': 0.00; 'subject:: [': 0.04; 'subject:Python': 0.06; 'lookup': 0.09; 'subject:method': 0.09; 'subject:set': 0.09; 'that).': 0.09; 'cc:addr:python-list': 0.11; 'mostly': 0.14; 'bind': 0.16; 'callable.': 0.16; 'descriptor': 0.16; 'evaluating': 0.16; 'fabio': 0.16; 'invoking': 0.16; 'subject:Dev': 0.16; 'url:pocoo': 0.16; 'sat,': 0.16; 'wrote:': 0.18; 'bit': 0.19; 'subject:] ': 0.20; 'seems': 0.21; '(the': 0.22; 'email addr:gmail.com>': 0.22; 'cc:addr:python.org': 0.22; 'simpler': 0.24; 'cc:2**0': 0.24; '>': 0.26; 'post': 0.26; 'header:In-Reply-To:1': 0.27; 'am,': 0.29; 'related': 0.29; "doesn't": 0.30; 'is?': 0.30; 'message-id:@mail.gmail.com': 0.30; "i'm": 0.30; 'url:mailman': 0.30; 'comments': 0.31; 'class': 0.32; 'url:python': 0.33; 'actual': 0.34; 'maybe': 0.34; 'could': 0.34; 'something': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'really': 0.36; 'curious': 0.36; 'url:listinfo': 0.36; 'method': 0.36; 'thanks': 0.36; 'url:org': 0.36; 'changing': 0.37; 'so,': 0.37; 'nov': 0.38; 'pm,': 0.38; 'does': 0.39; 'though,': 0.39; 'sure': 0.39; 'url:mail': 0.40; 'how': 0.40; 'future': 0.60; 'ian': 0.60; 'break': 0.61; 'skip:t 30': 0.61; 'course': 0.61; 'more': 0.64; 'to:addr:gmail.com': 0.65; 'worth': 0.66; '"look': 0.84; 'python-dev': 0.84; 'url:2014': 0.84; 'reasons,': 0.91; 'technique': 0.93; 'url:16': 0.93 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=z/ORTI99KLLCeDHc9c9+9gjULJtX9N9h4PnMsswA3lw=; b=D+HpNhpwlTnn0lu4/A2PAkYXOWQIvK5ghW+mKSzoV/0LxCxbGa5YK82jgezx0w8/2I rBVPaGpwNr0sDRXDTszZNGRMCD4H/c47eqoWmTYHNfN9zBVBNnKykTo958lgwh+7Iq3z uP1QScOSgqsaz65U1bIjnTNLM3vDnuF/GuqpNyhw8l7MzAozF8AEwjBz5Kvng3wPGf9v lBm/MMpAUNgwA7+YfTQYCgqNopn+0jksy5takE4SOaEWny6dulxOHrGnfGGsXx+ZM0iT c+LzDWJEl9swMW/zId01k2wqPwL8a2wa7K7U6VtYbhoC4cHvAwY3oVsacqFJ0pEVFEPA vHrA== X-Received: by 10.194.205.132 with SMTP id lg4mr62762114wjc.84.1415806457965; Wed, 12 Nov 2014 07:34:17 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <545919B6.7040007@stoneleaf.us> <87a943qyvn.fsf@handshake.de> <545CC204.2010301@stoneleaf.us> <8761eq424e.fsf@handshake.de> From: Fabio Zadrozny Date: Wed, 12 Nov 2014 13:33:57 -0200 Subject: Re: [Python-Dev] Dinamically set __call__ method To: Ian Kelly Content-Type: multipart/alternative; boundary=047d7bb7094202a83f0507ab2175 Cc: Python X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 87 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1415806493 news.xs4all.nl 2913 [2001:888:2000:d::a6]:55993 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:80610 --047d7bb7094202a83f0507ab2175 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 11, 2014 at 5:43 AM, Ian Kelly wrote: > On Sat, Nov 8, 2014 at 3:31 PM, Gregory Ewing > wrote: > > (BTW, I'm actually surprised that this technique makes c callable. > > There must be more going on that just "look up __call__ in the class > > object", because evaluating C.__call__ just returns the descriptor > > and doesn't invoking the descriptor mechanism.) > > But of course it doesn't just lookup C.__call__, because it has to > bind the method to the instance before calling it, which means > invoking the descriptor protocol. The actual lookup is more like: > > type(a).__dict__['__call__'].__get__(a, type(a)) > -- > https://mail.python.org/mailman/listinfo/python-list > 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). Thanks and Best Regards, Fabio --047d7bb7094202a83f0507ab2175 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Nov 11, 2014 at 5:43 AM, Ian Kelly <ian.g.kelly@gmail.com&= gt; wrote:
On Sat, Nov 8, 2014 = at 3:31 PM, Gregory Ewing
<greg.ewing@canterbury.ac= .nz> wrote:
> (BTW, I'm actually surprised that this technique makes c callable.=
> There must be more going on that just "look up __call__ in the cl= ass
> object", because evaluating C.__call__ just returns the descripto= r
> and doesn't invoking the descriptor mechanism.)

But of course it doesn't just lookup C.__call__, because it has = to
bind the method to the instance before calling it, which means
invoking the descriptor protocol. The actual lookup is more like:

type(a).__dict__['__call__'].__get__(a, type(a))
--
https://mail.python.org/mailman/listinfo/python-list


<= /div>
As a reference, I recently found a blog pos= t related to that:=C2=A0http://lucumr.pocoo.org/2014/8/16/the-python-i-w= ould-like-to-see/ (the Slots part comments on that).

It does seem a bit count= er-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.: ins= tead of the approach which would seem simpler which would do getattr(a, = 9;__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 wh= ich python-dev would consider worth changing in the future -- not sure how = much could break because of that though).
<= br>
Thanks and Best Regards,

Fabio
--047d7bb7094202a83f0507ab2175--