> On 24 Jul 2015, at 16:17, Nick Coghlan <ncogh...@gmail.com> wrote:
>
> On 23 July 2015 at 03:12, Steve Dower <steve.do...@microsoft.com
> <mailto:steve.do...@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.
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 | ncogh...@gmail.com <mailto:ncogh...@gmail.com> |
> Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org <mailto:Python-Dev@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>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
