Hi,
On Tue, Jun 12, 2007 at 08:10:26PM +1200, Greg Ewing wrote:
> Rather than spend time tinkering with the lookup order,
> it might be more productive to look into implementing
> a cache for attribute lookups.
See patch #1700288.
Armin
___
Python-Dev
On Tue, Jun 12, 2007 at 08:10:26PM +1200, Greg Ewing wrote:
> Phillip J. Eby wrote:
> > ...at the cost of slowing down access to properties and __slots__, by
> > adding an *extra* dictionary lookup there.
>
> Rather than spend time tinkering with the lookup order,
> it might be more productive to
Phillip J. Eby wrote:
> ...at the cost of slowing down access to properties and __slots__, by
> adding an *extra* dictionary lookup there.
Rather than spend time tinkering with the lookup order,
it might be more productive to look into implementing
a cache for attribute lookups. That would help w
Hi Eyal,
On Sun, Jun 10, 2007 at 04:13:38AM +0300, Eyal Lotem wrote:
> I must be missing something, as I really see no reason to keep the
> existing semantics other than backwards compatibility (which can be
> achieved by introducing a __fastattr__ or such).
>
> Can you explain under which situat
While you're at it, it would be nice to fix this ugly asymmetry I found in
descriptors. It seems that descriptor's __get__ is called even when
accessed from a class rather than instance, but __set__ is only invoked from
instances, never from classes:
class Descr(object):
def __get__(self, ob
On Sun, Jun 10, 2007, Eyal Lotem wrote:
>
> Python, probably through the valid assumption that most attribute
> lookups go to the class, tries to look for the attribute in the class
> first, and in the instance, second.
>
> What Python currently does is quite peculiar!
> Here's a short descriptio
I must be missing something, as I really see no reason to keep the
existing semantics other than backwards compatibility (which can be
achieved by introducing a __fastattr__ or such).
Can you explain under which situations or find any example situation
where the existing semantics are desirable?
I agree with Phillip with regard to the semantics. They are semantically
desirable. However, there is a patch to add a mro cache to speed up these
sorts of cases on the Python tracker, originally submitted by Armin Rigo.
He saw ~20% speedups, others see less. It is currently just sitting there
At 12:23 AM 6/10/2007 +0300, Eyal Lotem wrote:
>A. It will break code that uses instance.__dict__['var'] directly,
>when 'var' exists as a property with a __set__ in the class. I believe
>this is not significant.
>B. It will simplify getattr's semantics. Python should _always_ give
>precedence to i
> On 6/10/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 6/9/07, Eyal Lotem <[EMAIL PROTECTED]> wrote:
> > > I believe that this should be changed, so that Python first looks for
> > > the attribute in the instance's dict and only then through the dict's
> > > mro.
> >
> > Are you suggesting
On 6/9/07, Eyal Lotem <[EMAIL PROTECTED]> wrote:
> I believe that this should be changed, so that Python first looks for
> the attribute in the instance's dict and only then through the dict's
> mro.
[snip]
> What do you think?
Are you suggesting that the following code should print "43" instead o
11 matches
Mail list logo
