[Python-Dev] PEP 447 (type.__getdescriptor__)
ronaldoussoren at mac.com
Sun Jul 26 11:41:53 CEST 2015
> On 26 Jul 2015, at 09:14, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>> On 25 Jul 2015, at 17:39, Mark Shannon <mark at hotpy.org <mailto:mark at hotpy.org>> wrote:
>> On 22/07/15 09:25, Ronald Oussoren wrote:> Hi,
>>> Another summer with another EuroPython, which means its time again to
>>> try to revive PEP 447…
>> IMO, there are two main issues with the PEP and implementation.
>> 1. The implementation as outlined in the PEP is infinitely recursive, since the
>> lookup of "__getdescriptor__" on type must necessarily call
>> The implementation (in C) special cases classes that inherit "__getdescriptor__"
>> from type. This special casing should be mentioned in the PEP.
> Sure. An alternative is to slightly change the the PEP: use __getdescriptor__ when
> present and directly peek into __dict__ when it is not, and then remove the default
> The reason I didn’t do this in the PEP is that I prefer a programming model where
> I can explicitly call the default behaviour.
I’m not sure there is a problem after all (but am willing to use the alternative I describe above),
although that might be because I’m too much focussed on CPython semantics.
The __getdescriptor__ method is a slot in the type object and because of that the
normal attribute lookup mechanism is side-stepped for methods implemented in C. A
__getdescriptor__ that is implemented on Python is looked up the normal way by the
C function that gets added to the type struct for such methods, but that’s not a problem for
That’s not new for __getdescriptor__ but happens for most other special methods as well,
as I noted in my previous mail, and also happens for the __dict__ lookup that’s currently
used (t.__dict__ is an attribute and should be lookup up using __getattribute__, …)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev