PJE wrote:
> Isn't the simplest way to cache attribute
> lookups to just have a cache dictionary in the type,
> and update that dictionary whenever a change is
> made to a superclass? That's essentially how
> __slotted__ attribute changes on base classes
> work now, isn't it?
Neil Toronto wrote
Phillip J. Eby wrote:
> At 10:17 PM 12/3/2007 -0700, Neil Toronto wrote:
>> Interesting. But I'm going to have to say it probably wouldn't work as
>> well, since C code can and does alter tp_dict directly. Those places in
>> the core would have to be altered to invalidate the cache.
>
> Eh? Where
Phillip J. Eby wrote:
> At 03:51 PM 12/3/2007 -0800, Guido van Rossum wrote:
>> On Dec 3, 2007 3:48 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> > Actually, you're missing the part where such evil code *can't* muck
>> > things up for class dictionaries. Type dicts aren't reachable via
>> > ord
At 10:17 PM 12/3/2007 -0700, Neil Toronto wrote:
>Phillip J. Eby wrote:
> > Actually, you're missing the part where such evil code *can't* muck
> > things up for class dictionaries. Type dicts aren't reachable via
> > ordinary Python code; you *have* to modify them via setattr. (The
> > __dict__
I apologize - I had forgotten what you were telling me by the time I
replied. Here's a better answer.
> Phillip J. Eby wrote:
>> At 03:26 PM 12/3/2007 -0700, Neil Toronto wrote:
>> Actually, you're missing the part where such evil code *can't* muck
>> things up for class dictionaries. Type dict
At 03:51 PM 12/3/2007 -0800, Guido van Rossum wrote:
>On Dec 3, 2007 3:48 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > Actually, you're missing the part where such evil code *can't* muck
> > things up for class dictionaries. Type dicts aren't reachable via
> > ordinary Python code; you *have*
Phillip J. Eby wrote:
> At 03:26 PM 12/3/2007 -0700, Neil Toronto wrote:
>> Phillip J. Eby wrote:
>> > At 12:27 PM 12/3/2007 -0700, Neil Toronto wrote:
>> Some version of the non-string keys problem would exist with any caching
>> mechanism, though. An evil rich compare can always monkey about with
On Dec 3, 2007 3:48 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Actually, you're missing the part where such evil code *can't* muck
> things up for class dictionaries. Type dicts aren't reachable via
> ordinary Python code; you *have* to modify them via setattr. (The
> __dict__ of types retur
At 03:26 PM 12/3/2007 -0700, Neil Toronto wrote:
>Phillip J. Eby wrote:
> > At 12:27 PM 12/3/2007 -0700, Neil Toronto wrote:
> >> Guido van Rossum wrote:
> >> > How about subclasses of str? These have all the same issues...
> >>
> >> Yeah. I ended up having it, per class, permanently revert to unca
Phillip J. Eby wrote:
> At 12:27 PM 12/3/2007 -0700, Neil Toronto wrote:
>> Guido van Rossum wrote:
>> > How about subclasses of str? These have all the same issues...
>>
>> Yeah. I ended up having it, per class, permanently revert to uncached
>> lookups when it detects that a class dict in the MRO
At 12:27 PM 12/3/2007 -0700, Neil Toronto wrote:
>Guido van Rossum wrote:
> > On Dec 2, 2007 12:49 PM, Neil Toronto <[EMAIL PROTECTED]> wrote:
> >> It turned out not *that* hard to code around for attribute caching, and
> >> the extra cruft only gets invoked on a cache miss. The biggest problem
> >
Guido van Rossum wrote:
> On Dec 2, 2007 12:49 PM, Neil Toronto <[EMAIL PROTECTED]> wrote:
>> It turned out not *that* hard to code around for attribute caching, and
>> the extra cruft only gets invoked on a cache miss. The biggest problem
>> isn't speed - it's that it's possible (though extremely
On Dec 2, 2007 12:49 PM, Neil Toronto <[EMAIL PROTECTED]> wrote:
> It turned out not *that* hard to code around for attribute caching, and
> the extra cruft only gets invoked on a cache miss. The biggest problem
> isn't speed - it's that it's possible (though extremely unlikely), while
> testing ke
On Dec 2, 2007 6:28 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I don't see a problem with requiring dictionary key comparisons to be
> side-effect-free - even in the general case of dictionaries, not just
> namespace ones.
Me neither -- but the problem is enforcement.
--
--Guido van Rossum
At 08:09 PM 12/1/2007 -0700, Neil Toronto wrote:
>Are there any use-cases for allowing namespace dicts (such as globals,
>builtins and classes) to have non-string keys?
Yes. See http://pypi.python.org/pypi/AddOns
> I'm asking because I'm
>planning on accelerating method lookups next, and the p
Neil Toronto wrote:
> It'd be nice to have a benchmark with a deep class hierarchy. Does
> anybody know of one?
Zope has some very complex and deep class hierarchies, especially when
it comes down to Plone and Archetypes. Unfortunately Zope is still stuck
with Python 2.4.
Christian
_
On Sun, Dec 02, 2007, Neil Toronto wrote:
>
> Anyway, report: I've got an initial working attribute cache, using the
> conveniently-named-and-left-NULL tp_cache. It's a nice speedup - except
> on everything the standard benchmarks test, because their class
> hierarchies are very shallow. :p If
Nicko van Someren wrote:
> On 2 Dec 2007, at 03:09, Neil Toronto wrote:
>
>> Are there any use-cases for allowing namespace dicts (such as globals,
>> builtins and classes) to have non-string keys? I'm asking because I'm
>> planning on accelerating method lookups next, and the possibility of a
>>
On 2 Dec 2007, at 03:09, Neil Toronto wrote:
> Are there any use-cases for allowing namespace dicts (such as globals,
> builtins and classes) to have non-string keys? I'm asking because I'm
> planning on accelerating method lookups next, and the possibility of a
> key compare changing the underlyi
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| On Dec 1, 2007 7:09 PM, Neil Toronto <[EMAIL PROTECTED]> wrote:
| > Are there any use-cases for allowing namespace dicts (such as globals,
| > builtins and classes) to have non-string keys? I'm asking because I'm
| >
On Dec 1, 2007 7:09 PM, Neil Toronto <[EMAIL PROTECTED]> wrote:
> Are there any use-cases for allowing namespace dicts (such as globals,
> builtins and classes) to have non-string keys? I'm asking because I'm
> planning on accelerating method lookups next, and the possibility of a
> key compare cha
Are there any use-cases for allowing namespace dicts (such as globals,
builtins and classes) to have non-string keys? I'm asking because I'm
planning on accelerating method lookups next, and the possibility of a
key compare changing the underlying dict could be a major pain. (It was
a minor pai
22 matches
Mail list logo
