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
Hi.
I was surprised to find in my profiling that instance variable access
was pretty slow.
I looked through the CPython code involved, and discovered something
that really surprises me.
Python, probably through the valid assumption that most attribute
lookups go to the class, tries to look for t
12 matches
Mail list logo
