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

[Brett Cannon]

 On Fri, Jul 24, 2015, 07:43 Ronald Oussoren <ronaldoussoren at mac.com> wrote:

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> 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):

       pass

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

   class MyType:

       @classmethod

       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.


Leave the decorator out like __new__, otherwise people are bound to forget
it and have a hard time debugging why their code doesn't work.

-Brett


Ronald

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   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev


 Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com

 _______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/brett%40python.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150724/4dccb8bc/attachment.html>