On Thu, Sep 19, 2013 at 3:49 AM, Ronald Oussoren wrote:
> On 14 Sep, 2013, at 8:30, Nick Coghlan wrote:
> > However, I agree the current wording only conveys that to the handful
> > of people that already know exactly when in the attribute lookup
> > sequence that step occurs, which is a rather n
On Thu, Sep 19, 2013 at 4:12 AM, Nick Coghlan wrote:
> On 19 Sep 2013 20:00, "Paul Moore" wrote:
> >
> > On 19 September 2013 10:32, Ronald Oussoren
> wrote:
> > > The first time a method is called the bridge looks for an Objective-C
> selector
> > > with the same name and adds that to the clas
On Thu, Sep 19, 2013 at 4:04 AM, Ronald Oussoren wrote:
> The C code uses PyDict_GetItem and AFAIK that doesn't look for a
> __getitem__
> implementation in a subclass.
>
Yeah, the PyDict_* API is definitely not subclass friendly. :(
-eric
___
Python-D
On 14 Sep, 2013, at 8:30, Nick Coghlan wrote:
>
>
>>> but the *primary* purpose is to
>>> customise the retrieval of objects that will be checked to see if they're
>>> descriptors.
>>
>> If that's the case, the PEP should make that clear.
>
> Technically, that's what "Currently object.__geta
On 19 Sep, 2013, at 12:12, Nick Coghlan wrote:
>
> On 19 Sep 2013 20:00, "Paul Moore" wrote:
> >
> > On 19 September 2013 10:32, Ronald Oussoren wrote:
> > > The first time a method is called the bridge looks for an Objective-C
> > > selector
> > > with the same name and adds that to the cla
On 19 Sep 2013 20:00, "Paul Moore" wrote:
>
> On 19 September 2013 10:32, Ronald Oussoren
wrote:
> > The first time a method is called the bridge looks for an Objective-C
selector
> > with the same name and adds that to the class dictionary. This works
fine for normal
> > method lookups, by overr
On 19 Sep, 2013, at 12:00, Paul Moore wrote:
> On 19 September 2013 10:32, Ronald Oussoren wrote:
>> The first time a method is called the bridge looks for an Objective-C
>> selector
>> with the same name and adds that to the class dictionary. This works fine
>> for normal
>> method lookups,
On 19 September 2013 10:32, Ronald Oussoren wrote:
> The first time a method is called the bridge looks for an Objective-C selector
> with the same name and adds that to the class dictionary. This works fine for
> normal
> method lookups, by overriding __getattribute__, but causes problems with
On 14 Sep, 2013, at 8:30, Nick Coghlan wrote:
[... interesting text that I'll respond to later ...]
>
> So my proposed name is based on the idea that what Ronald is after
> with the PEP is a hook that *only* gets invoked when the interpreter
> is doing this hunt for descriptors, but *not* for
On 13 Sep, 2013, at 18:19, Steve Dower wrote:
> From: Steven D'Aprano
>> On Fri, Sep 13, 2013 at 04:26:06AM +, Steve Dower wrote:
>>
>>> Last I checked, looking up in the instance dict us exactly what it
>>> does. Even the example you posted is doing that.
>>
>> The example from the PEP sh
On 13 Sep, 2013, at 14:23, Steven D'Aprano wrote:
> On Fri, Sep 13, 2013 at 08:42:46PM +1000, Nick Coghlan wrote:
>> Perhaps "__getdescriptor__" would work as the method name? Yes, it can
>> technically return a non-descriptor,
>
> So technically that name is, um, what's the term... oh yes, "a
On 13 Sep, 2013, at 12:42, Nick Coghlan wrote:
> Perhaps "__getdescriptor__" would work as the method name? Yes, it can
> technically return a non-descriptor, but the *primary* purpose is to
> customise the retrieval of objects that will be checked to see if they're
> descriptors. It *won't*
On 13 September 2013 22:23, Steven D'Aprano wrote:
> On Fri, Sep 13, 2013 at 08:42:46PM +1000, Nick Coghlan wrote:
>> Perhaps "__getdescriptor__" would work as the method name? Yes, it can
>> technically return a non-descriptor,
>
> So technically that name is, um, what's the term... oh yes, "a li
From: Steven D'Aprano
> On Fri, Sep 13, 2013 at 04:26:06AM +, Steve Dower wrote:
>
>> Last I checked, looking up in the instance dict us exactly what it
>> does. Even the example you posted is doing that.
>
> The example from the PEP shows:
>
> return cls.__dict__[name]
>
> not "self.__dict
On Fri, Sep 13, 2013 at 08:42:46PM +1000, Nick Coghlan wrote:
> Perhaps "__getdescriptor__" would work as the method name? Yes, it can
> technically return a non-descriptor,
So technically that name is, um, what's the term... oh yes, "a lie".
:-)
> but the *primary* purpose is to
> customise t
Perhaps "__getdescriptor__" would work as the method name? Yes, it can
technically return a non-descriptor, but the *primary* purpose is to
customise the retrieval of objects that will be checked to see if they're
descriptors. It *won't* be invoked when looking for ordinary attributes in
an instanc
On Fri, Sep 13, 2013 at 04:26:06AM +, Steve Dower wrote:
> Last I checked, looking up in the instance dict us exactly what it
> does. Even the example you posted is doing that.
The example from the PEP shows:
return cls.__dict__[name]
not "self.__dict__[name]". It is true that "the ins
ne of those.
Cheers,
Steve
Sent from my Windows Phone
From: Steven D'Aprano<mailto:st...@pearwood.info>
Sent: 9/12/2013 21:00
To: python-dev@python.org<mailto:python-dev@python.org>
Subject: Re: [Python-Dev] PEP 447: add type.__locallookup__
O
On Fri, Sep 13, 2013 at 03:04:49AM +, Steve Dower wrote:
> What about __getlocalattribute__ or __getattributenorecurse__? Long,
> but this isn't going to be used often.
This has nothing to do with locals, nor does it have anything to do with
recursion, so both those names are misleading.
r the top post.)
Sent from my Windows Phone
From: Steven D'Aprano<mailto:st...@pearwood.info>
Sent: 9/12/2013 16:09
To: python-dev@python.org<mailto:python-dev@python.org>
Subject: Re: [Python-Dev] PEP 447: add type.__locallookup__
On Thu, Sep 12,
> On 12 sep. 2013, at 17:30, "R. David Murray" wrote:
>
>> On Thu, 12 Sep 2013 16:42:39 +0200, Ronald Oussoren
>> wrote:
>>
>>> On 9 Sep, 2013, at 20:23, Jan Kaliszewski wrote:
>>>
>>> Is '__locallookup__' a really good name? In Python, *local* --
>>> especially in context of *lookups* --
On Thu, Sep 12, 2013 at 04:42:39PM +0200, Ronald Oussoren wrote:
> I don't particularly like __locallookup__ either, but haven't found a
> better name yet. "__lookup_in_class__" was the best alternative I
> could come up with, and that feels different than other special
> methods. The name in
On 9 Sep, 2013, at 23:18, Mark Shannon wrote:
> On 09/09/13 15:30, Ethan Furman wrote:
>> On 07/30/2013 11:17 PM, Ronald Oussoren wrote:
>>>
>>> And something I forgot to ask: is anyone willing to be the
>>> BDFL-Delegate for
>>> PEP 447?
>>
>> *Bump*.
>>
>> It would be nice if this could mak
On Thu, 12 Sep 2013 16:42:39 +0200, Ronald Oussoren
wrote:
>
> On 9 Sep, 2013, at 20:23, Jan Kaliszewski wrote:
>
> > Is '__locallookup__' a really good name? In Python, *local* --
> > especially in context of *lookups* -- usually associates with
> > locals() i.e. a namespace of a function/met
On 9 Sep, 2013, at 17:43, Mark Shannon wrote:
> I would like time to investigate this further, but at the moment I think it
> will either make attribute lookup poorly defined or slow.
>
> Of the top of my head, the problem as a I see it is basically this:
> Currently, type.__getattribute__() i
On 9 Sep, 2013, at 20:23, Jan Kaliszewski wrote:
> Is '__locallookup__' a really good name? In Python, *local* -- especially in
> context of *lookups* -- usually associates with locals() i.e. a namespace of
> a function/method execution frame or a namespace of a class, during
> *definition* o
Hi Mark,
On Mon, Sep 9, 2013 at 11:18 PM, Mark Shannon wrote:
> 5. Other implementations. What do the Jython/IronPython/PyPy developers
> think?
Thanks for asking :-) I'm fine with staying out of language design
issues like this one, and I believe it's the general concensus in
PyPy. Whatever g
On 09/09/13 22:25, Benjamin Peterson wrote:
2013/9/9 Mark Shannon :
On 09/09/13 15:30, Ethan Furman wrote:
On 07/30/2013 11:17 PM, Ronald Oussoren wrote:
And something I forgot to ask: is anyone willing to be the
BDFL-Delegate for
PEP 447?
*Bump*.
It would be nice if this could make int
2013/9/9 Mark Shannon :
> On 09/09/13 15:30, Ethan Furman wrote:
>>
>> On 07/30/2013 11:17 PM, Ronald Oussoren wrote:
>>>
>>>
>>> And something I forgot to ask: is anyone willing to be the
>>> BDFL-Delegate for
>>> PEP 447?
>>
>>
>> *Bump*.
>>
>> It would be nice if this could make into 3.4.
>>
>
>
On 09/09/13 15:30, Ethan Furman wrote:
On 07/30/2013 11:17 PM, Ronald Oussoren wrote:
And something I forgot to ask: is anyone willing to be the
BDFL-Delegate for
PEP 447?
*Bump*.
It would be nice if this could make into 3.4.
IMO, there are some issues that need to be addressed before PEP
Since the main problem is super(), maybe we can just add a __super__
method to get a custom super implementation?
2013/9/9 Ethan Furman :
> On 07/30/2013 11:17 PM, Ronald Oussoren wrote:
>>
>>
>> And something I forgot to ask: is anyone willing to be the BDFL-Delegate
>> for
>> PEP 447?
>
>
> *Bum
Yes, I don't like the 'local' prefix too. How about '__dictlookup__'?
It's just more self-describing.
Yury
On 2013-09-09, at 2:23 PM, Jan Kaliszewski wrote:
> Is '__locallookup__' a really good name? In Python, *local* -- especially in
> context of *lookups* -- usually associates with locals(
Is '__locallookup__' a really good name? In Python, *local* --
especially in context of *lookups* -- usually associates with locals()
i.e. a namespace of a function/method execution frame or a namespace of
a class, during *definition* of that class... So '__locallookup__' can
be confusing.
Wh
On Mon, 09 Sep 2013 09:05:57 -0700
Ethan Furman wrote:
> On 09/09/2013 08:43 AM, Mark Shannon wrote:
> > I would like time to investigate this further, but at the moment I think it
> > will either make attribute lookup poorly
> > defined or slow.
> >
> > Of the top of my head, the problem as a I
On 09/09/2013 08:43 AM, Mark Shannon wrote:
I would like time to investigate this further, but at the moment I think it
will either make attribute lookup poorly
defined or slow.
Of the top of my head, the problem as a I see it is basically this:
Currently, type.__getattribute__() is a fixed poi
I would like time to investigate this further, but at the moment I think it
will either make attribute lookup poorly defined or slow.
Of the top of my head, the problem as a I see it is basically this:
Currently, type.__getattribute__() is a fixed point in the lookup of attributes.
The proposal
I'll look into it this evening.
On 09/09/13 17:03, Guido van Rossum wrote:
OK, how much time do you need?
--Guido van Rossum (sent from Android phone)
On Sep 9, 2013 8:44 AM, "Mark Shannon" mailto:m...@hotpy.org>>
wrote:
I would like time to investigate this further, but at the moment I
OK, how much time do you need?
--Guido van Rossum (sent from Android phone)
On Sep 9, 2013 8:44 AM, "Mark Shannon" wrote:
> I would like time to investigate this further, but at the moment I think
> it will either make attribute lookup poorly defined or slow.
>
> Of the top of my head, the probl
Let's just accept this PEP. It looks like a nice addition to the metaclass
machinery and I don't think we'll get much more useful feedback by waiting.
On Mon, Sep 9, 2013 at 7:30 AM, Ethan Furman wrote:
> On 07/30/2013 11:17 PM, Ronald Oussoren wrote:
>
>>
>> And something I forgot to ask: is a
On 07/30/2013 11:17 PM, Ronald Oussoren wrote:
And something I forgot to ask: is anyone willing to be the BDFL-Delegate for
PEP 447?
*Bump*.
It would be nice if this could make into 3.4.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
On 29 Jul, 2013, at 14:49, Ronald Oussoren wrote:
> Hi,
>
> This PEP proposed to add a __locallookup__ slot to type objects,
> which is used by _PyType_Lookup and super_getattro instead of peeking
> in the tp_dict of classes. The PEP text explains why this is needed.
>
> Differences with the
Le Mon, 29 Jul 2013 15:26:41 +0200,
Ronald Oussoren a écrit :
>
> On 29 Jul, 2013, at 15:07, Ronald Oussoren
> wrote:
>
> >
> > On 29 Jul, 2013, at 14:58, Antoine Pitrou
> > wrote:
> >
> >>
> >> Hi,
> >>
> >> Le Mon, 29 Jul 2013 14:49:18 +0200,
> >> Ronald Oussoren a écrit :
> >>> Hi,
> >
On 29 Jul, 2013, at 15:07, Ronald Oussoren wrote:
>
> On 29 Jul, 2013, at 14:58, Antoine Pitrou wrote:
>
>>
>> Hi,
>>
>> Le Mon, 29 Jul 2013 14:49:18 +0200,
>> Ronald Oussoren a écrit :
>>> Hi,
>>>
>>> This PEP proposed to add a __locallookup__ slot to type objects,
>>> which is used by _
On 29 Jul, 2013, at 14:58, Antoine Pitrou wrote:
>
> Hi,
>
> Le Mon, 29 Jul 2013 14:49:18 +0200,
> Ronald Oussoren a écrit :
>> Hi,
>>
>> This PEP proposed to add a __locallookup__ slot to type objects,
>> which is used by _PyType_Lookup and super_getattro instead of peeking
>> in the tp_dic
Hi,
Le Mon, 29 Jul 2013 14:49:18 +0200,
Ronald Oussoren a écrit :
> Hi,
>
> This PEP proposed to add a __locallookup__ slot to type objects,
> which is used by _PyType_Lookup and super_getattro instead of peeking
> in the tp_dict of classes. The PEP text explains why this is needed.
>
> Diffe
Hi,
This PEP proposed to add a __locallookup__ slot to type objects,
which is used by _PyType_Lookup and super_getattro instead of peeking
in the tp_dict of classes. The PEP text explains why this is needed.
Differences with the previous version:
* Better explanation of why this is a useful add
46 matches
Mail list logo
