[Python-Dev] PEP 447 (type.__getdescriptor__)

[Ronald Oussoren]

> 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:
>> 
>> Hi,
>> 
>> 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
>> type.__getdescriptor__.
>> 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
> __getdescriptor__. 
> 
> 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
type itself.

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__, …)

Ronald
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150726/9cfd3da5/attachment.html>