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

Ronald Oussoren ronaldoussoren at mac.com
Fri Jul 24 16:43:06 CEST 2015

> On 24 Jul 2015, at 16:17, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 23 July 2015 at 03:12, Steve Dower <Steve.Dower at microsoft.com <mailto:Steve.Dower at microsoft.com>> wrote:
>> Terry Reedy wrote:
>>> On 7/22/2015 3:25 AM, Ronald Oussoren wrote:
>>>> Hi,
>>>> Another summer with another EuroPython, which means its time again to
>>>> try to revive PEP 447…
>>>> I’ve just pushes a minor update to the PEP and would like to get some
>>>> feedback on this, arguably fairly esoteric, PEP.
>>> Yeh, a bit too esoteric for most of us to review. For instance, it is not
>>> obvious to me, not familiar with internal details, after reading the intro, why
>>> a custom __getattribute__ is not enough and why __getdescriptor__ would be
>>> needed. If Guido does not want to review this, you need to find a PEP BDFL for
>>> this.
>>> There are two fairly obvious non-esoteric questions:
>>> 1. How does this impact speed (updated section needed)?
>> Agreed, this is important. But hopefully it's just a C indirection (or better yet, a null check) for objects that don't override __getdescriptor__.
>>> 2. Is this useful, that you can think of, for anything other than connecting to
>>> Objective C?
>> There are other object models that would benefit from this, but I don't recall that we came up with uses other than "helps proxy to objects where listing all members eagerly is expensive and/or potentially incorrect". Maybe once you list all the operating systems that are now using dynamic object-oriented APIs rather than flat APIs (Windows, iOS, Android, ... others?) this is good enough?
> "better bridging to other languages and runtimes" is a good enough
> rationale for me, although I also wonder if it might be useful for
> making some interesting COM and dbus based API wrappers.
> Ronald, could you dig up a reference to the last thread (or threads)
> on this? My recollection is that we were actually pretty happy with
> it, and it was just set aside through lack of time to push it through
> to completion.

I’ll do some digging in my archives. From what I recall you and Steve were positive the last time around and others didn’t have much to add at the time.

FWIW Guido was positive about the idea, but would really like to see up to date benchmark results and some specific micro benchmarking to see if the change has negative performance impact.

I do have a API design question now that I’m working on this again: the PEP proposed to add a __getdescriptor__ method to the meta type, that is you’d define it as:

   class MyMeta (type):
        def __getdescriptor__(self, name): …

   class MyType (object, metaclass=MyMeta):

This doesn’t match how other special slots are done, in particular __new__. I’d like to switch the definition to:

   class MyType:

       def __getdescriptor__(cls, name): …

I have two questions about that: (1) is this indeed a better interface and (2) should users explicitly use the classmethod decorator or would it be better to match the behaviour for __new__ by leaving that out?     Personally I do think that this is a better interface, but am not sure about requiring the decorator.


P.S. Fighting with refcounting between sessions, forward porting of the patch for this PEP seems to have introduced a refcount problem. Nothing that cannot be fixed during the sprints though.

> Regards,
> Nick.
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>   |   Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org <mailto:Python-Dev at python.org>
> https://mail.python.org/mailman/listinfo/python-dev <https://mail.python.org/mailman/listinfo/python-dev>
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com <https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150724/70024a31/attachment-0001.html>

More information about the Python-Dev mailing list