Re: [Python-ideas] Missing Core Feature: + - * / | & do not call getattr

Path	csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From	Ian Kelly <ian.g.kelly@gmail.com>
Newsgroups	comp.lang.python
Subject	Re: [Python-ideas] Missing Core Feature: + - * / \| & do not call __getattr__
Date	Fri, 4 Dec 2015 09:41:39 -0600
Lines	32
Message-ID	<mailman.199.1449243747.14615.python-list@python.org> (permalink)
References	<CAOs8ta06yhq+C+w805k53fpMwqzDD0MuWnLt7b=vxazvr_N1fQ@mail.gmail.com>
Mime-Version	1.0
Content-Type	text/plain; charset=UTF-8
X-Trace	news.uni-berlin.de mYeJybcvm6fqTc5sK0+nhQ78QXdP1mQUxiP8dI2nvpCQ==
Return-Path	<ian.g.kelly@gmail.com>
X-Original-To	python-list@python.org
Delivered-To	python-list@mail.python.org
X-Spam-Status	OK 0.005
X-Spam-Evidence	'H': 0.99; 'S': 0.00; 'subject:: [': 0.03; 'subject:Python': 0.05; 'attributes': 0.07; 'dynamically': 0.07; 'instances.': 0.09; 'stating': 0.09; 'python': 0.10; 'subject:not': 0.11; 'weird': 0.15; 'behaviour.': 0.16; 'received:io': 0.16; 'received:psf.io': 0.16; 'subject:ideas': 0.16; 'wrote:': 0.16; 'looked': 0.16; 'resolved': 0.18; 'solution.': 0.18; 'subject:] ': 0.19; 'all,': 0.20; '2015': 0.20; 'meant': 0.22; "aren't": 0.22; 'am,': 0.23; 'dec': 0.23; 'this:': 0.23; 'implemented': 0.24; 'header:In-Reply-To:1': 0.24; 'example': 0.26; 'define': 0.27; 'fri,': 0.27; 'least': 0.27; 'message-id:@mail.gmail.com': 0.27; 'idea': 0.28; '(although': 0.29; 'behaviour': 0.29; 'operators': 0.29; 'received:209.85.213.174': 0.29; 'objects': 0.29; 'skip:_ 10': 0.32; 'implement': 0.32; 'maybe': 0.33; 'point': 0.33; 'class': 0.33; 'url:python': 0.33; 'similar': 0.33; '(for': 0.34; 'correctly': 0.34; 'received:google.com': 0.35; 'generic': 0.35; 'instance': 0.35; 'but': 0.36; 'should': 0.36; 'there': 0.36; 'url:org': 0.36; 'received:209.85': 0.36; 'possible': 0.36; 'cases': 0.36; 'to:addr:python-list': 0.36; 'two': 0.37; 'received:209.85.213': 0.37; 'received:209': 0.38; 'why': 0.39; 'subject:-': 0.39; 'well.': 0.40; 'to:addr:python.org': 0.40; 'some': 0.40; 'url:3': 0.60; "you'll": 0.61; 'matter': 0.63; 'dear': 0.67; 'special': 0.73; 'viewed': 0.79; 'dict,': 0.84; 'regarded': 0.84; 'to:name:python': 0.84; 'url:datamodel': 0.84; 'url:reference': 0.91
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 :content-type; bh=ybPLbYJ/83/xGtTmUfYBReIgx4I478o8uO6ldrWki7Q=; b=BLTpuu2efYZMiaLPPMvWw+KgNQf4Orir/khHPpNZYTBRTRZYfMoPX1xxjYM5z5OEpU on0i3je0Sc6Za2iLv2CT1J64xVZ3RCAivcVJpvcUxgvfm6+rDxlLmdg0l+4kGnfPIVvW X9Gs5tMLH16afsO7ostslTVo+XhNJ0LSh8Z+mZTfsm2Q6CEZ0IWv6MOj4YpjYvy2b8dw Pv9gS8FcayOFHvSjxHBUVu6F+nj8rtGvQxYKChHu8QY3fhJlUbzopUsYd7oANGI2Qml1 6LQMWKybywXLjqBsK0JFU310kMNW87Q5J1UzhftFk7lSbaF5r6zmCCZoNVq5WcYdhB4f GV8Q==
X-Received	by 10.50.150.71 with SMTP id ug7mr4493679igb.68.1449243738884; Fri, 04 Dec 2015 07:42:18 -0800 (PST)
In-Reply-To	<CAOs8ta06yhq+C+w805k53fpMwqzDD0MuWnLt7b=vxazvr_N1fQ@mail.gmail.com>
X-BeenThere	python-list@python.org
X-Mailman-Version	2.1.20+
Precedence	list
List-Id	General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe	<https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive	<http://mail.python.org/pipermail/python-list/>
List-Post	<mailto:python-list@python.org>
List-Help	<mailto:python-list-request@python.org?subject=help>
List-Subscribe	<https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Xref	csiph.com comp.lang.python:100005

Show key headers only | View raw

On Fri, Dec 4, 2015 at 7:20 AM, Stephan Sahm <Stephan.Sahm@gmx.de> wrote:
> Dear all,
>
> I just stumbled upon a very weird behaviour of python 2 and python 3. At
> least I was not able to find a solution.
>
> The point is to dynamically define __add__, __or__ and so on via __getattr__
> (for example by deriving them from __iadd__ or similar in a generic way).
> However this very intuitive idea is currently NOT POSSIBLE because * - * / &
> | and so on just bypass this standard procedure.
>
> I found two stackoverflow contributions stating this:
> http://stackoverflow.com/questions/11629287/python-how-to-forward-an-instances-method-call-to-its-attribute
> http://stackoverflow.com/questions/33393474/lazy-evaluation-forward-operations-to-deferred-value
>
> Neither the mentioned posts, nor I myself can see any reason why this is the
> way it is, nor how the operators are actually implemented to maybe bypass
> this unintuitive behaviour.

The cited reason is "speed optimizations":
https://docs.python.org/3/reference/datamodel.html#special-method-lookup

But there may be other reasons as well. __getattr__ and
__getattribute__ are meant to implement *attribute* lookup. Special
methods are best not regarded as attributes (although they can be
looked up as such), but as implementation of class behavior. You'll
note that special methods also aren't resolved in the instance dict,
but only in the class dict; this is viewed as a matter of correctness,
so that special methods work correctly on class objects (invoking the
metaclass) as well as on instances. In some cases there may also be a
chicken-and-egg problem; should Python call __getattribute__ in order
to resolve the __getattribute__ method?

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

Thread

Re: [Python-ideas] Missing Core Feature: + - * / | & do not call __getattr__ Ian Kelly <ian.g.kelly@gmail.com> - 2015-12-04 09:41 -0600

csiph-web