On 13 Sep, 2013, at 12:42, Nick Coghlan ncogh...@gmail.com 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
On 13 Sep, 2013, at 18:19, Steve Dower steve.do...@microsoft.com 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
On 14 Sep, 2013, at 8:30, Nick Coghlan ncogh...@gmail.com 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,
On 19 September 2013 10:32, Ronald Oussoren ronaldousso...@mac.com 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
On 19 Sep, 2013, at 12:00, Paul Moore p.f.mo...@gmail.com wrote:
On 19 September 2013 10:32, Ronald Oussoren ronaldousso...@mac.com 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
On 19 Sep 2013 20:00, Paul Moore p.f.mo...@gmail.com wrote:
On 19 September 2013 10:32, Ronald Oussoren ronaldousso...@mac.com
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
On 19 Sep, 2013, at 12:12, Nick Coghlan ncogh...@gmail.com wrote:
On 19 Sep 2013 20:00, Paul Moore p.f.mo...@gmail.com wrote:
On 19 September 2013 10:32, Ronald Oussoren ronaldousso...@mac.com wrote:
The first time a method is called the bridge looks for an Objective-C
selector
On 14 Sep, 2013, at 8:30, Nick Coghlan ncogh...@gmail.com 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
On Thu, Sep 19, 2013 at 4:12 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 19 Sep 2013 20:00, Paul Moore p.f.mo...@gmail.com wrote:
On 19 September 2013 10:32, Ronald Oussoren ronaldousso...@mac.com
wrote:
The first time a method is called the bridge looks for an Objective-C
selector
On Thu, Sep 19, 2013 at 4:04 AM, Ronald Oussoren ronaldousso...@mac.comwrote:
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
On Thu, Sep 19, 2013 at 3:49 AM, Ronald Oussoren ronaldousso...@mac.comwrote:
On 14 Sep, 2013, at 8:30, Nick Coghlan ncogh...@gmail.com 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
On 13 September 2013 22:23, Steven D'Aprano st...@pearwood.info 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
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
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 instance
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 the
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__[name]. It
On 9 Sep, 2013, at 20:23, Jan Kaliszewski z...@chopin.edu.pl 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
On 9 Sep, 2013, at 17:43, Mark Shannon m...@hotpy.org 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,
On Thu, 12 Sep 2013 16:42:39 +0200, Ronald Oussoren ronaldousso...@mac.com
wrote:
On 9 Sep, 2013, at 20:23, Jan Kaliszewski z...@chopin.edu.pl wrote:
Is '__locallookup__' a really good name? In Python, *local* --
especially in context of *lookups* -- usually associates with
locals()
On 9 Sep, 2013, at 23:18, Mark Shannon m...@hotpy.org 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 make into
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 the
On 12 sep. 2013, at 17:30, R. David Murray rdmur...@bitdance.com wrote:
On Thu, 12 Sep 2013 16:42:39 +0200, Ronald Oussoren ronaldousso...@mac.com
wrote:
On 9 Sep, 2013, at 20:23, Jan Kaliszewski z...@chopin.edu.pl wrote:
Is '__locallookup__' a really good name? In Python, *local* --
Phone
From: Steven D'Apranomailto:st...@pearwood.info
Sent: 9/12/2013 16:09
To: python-dev@python.orgmailto:python-dev@python.org
Subject: Re: [Python-Dev] PEP 447: add type.__locallookup__
On Thu, Sep 12, 2013 at 04:42:39PM +0200, Ronald Oussoren wrote:
I
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.
of those.
Cheers,
Steve
Sent from my Windows Phone
From: Steven D'Apranomailto:st...@pearwood.info
Sent: 9/12/2013 21:00
To: python-dev@python.orgmailto:python-dev@python.org
Subject: Re: [Python-Dev] PEP 447: add type.__locallookup__
On Fri, Sep 13, 2013 at 03:04
Hi Mark,
On Mon, Sep 9, 2013 at 11:18 PM, Mark Shannon m...@hotpy.org 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
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
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 et...@stoneleaf.us wrote:
On 07/30/2013 11:17 PM, Ronald Oussoren wrote:
And something I forgot
OK, how much time do you need?
--Guido van Rossum (sent from Android phone)
On Sep 9, 2013 8:44 AM, Mark Shannon m...@hotpy.org 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,
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 m...@hotpy.org mailto:m...@hotpy.org
wrote:
I would like time to investigate this further, but at
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
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
On Mon, 09 Sep 2013 09:05:57 -0700
Ethan Furman et...@stoneleaf.us 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
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.
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 z...@chopin.edu.pl wrote:
Is '__locallookup__' a really good name? In Python, *local* -- especially in
context of *lookups* -- usually
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 et...@stoneleaf.us:
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?
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
2013/9/9 Mark Shannon m...@hotpy.org:
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
On 09/09/13 22:25, Benjamin Peterson wrote:
2013/9/9 Mark Shannon m...@hotpy.org:
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
On 29 Jul, 2013, at 14:49, Ronald Oussoren ronaldousso...@mac.com 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.
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
Hi,
Le Mon, 29 Jul 2013 14:49:18 +0200,
Ronald Oussoren ronaldousso...@mac.com 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
On 29 Jul, 2013, at 14:58, Antoine Pitrou solip...@pitrou.net wrote:
Hi,
Le Mon, 29 Jul 2013 14:49:18 +0200,
Ronald Oussoren ronaldousso...@mac.com a écrit :
Hi,
This PEP proposed to add a __locallookup__ slot to type objects,
which is used by _PyType_Lookup and super_getattro
On 29 Jul, 2013, at 15:07, Ronald Oussoren ronaldousso...@mac.com wrote:
On 29 Jul, 2013, at 14:58, Antoine Pitrou solip...@pitrou.net wrote:
Hi,
Le Mon, 29 Jul 2013 14:49:18 +0200,
Ronald Oussoren ronaldousso...@mac.com a écrit :
Hi,
This PEP proposed to add a __locallookup__
Le Mon, 29 Jul 2013 15:26:41 +0200,
Ronald Oussoren ronaldousso...@mac.com a écrit :
On 29 Jul, 2013, at 15:07, Ronald Oussoren ronaldousso...@mac.com
wrote:
On 29 Jul, 2013, at 14:58, Antoine Pitrou solip...@pitrou.net
wrote:
Hi,
Le Mon, 29 Jul 2013 14:49:18 +0200,
45 matches
Mail list logo
