I see now that my previous reply went only to Stefan, so I'm re-submitting,
this time to the list.
> -Original Message-
> From: Stefan Behnel
> Sent: Saturday, 04 September, 2010 04:29
>
> What about adding an intermediate namespace called "cache", so that
> the new operations are availab
On Sep 4, 2010, at 3:15 AM, Georg Brandl wrote:
> Am 04.09.2010 12:06, schrieb Antoine Pitrou:
>> On Sat, 04 Sep 2010 11:42:08 +0200
>> Éric Araujo wrote:
It's just a little more overhead, but I think it reads quite a bit better.
>>>
>>> Or we could use pseudo-namespacing: get_phone_
On Sep 4, 2010, at 11:20 AM, Antoine Pitrou wrote:
> Well, perhaps lru_cache() would have deserved a review before
> committing?
Not everything needs to be designed by committee.
This API is based on one that was published as a recipe
several years ago and has been used in a number of
companies.
On Sat, 4 Sep 2010 09:21:25 -0500
Daniel Stutzbach wrote:
>
> I have been using a similar LRU cache class to store items retrieved from a
> database. In my case, a decorator-paradigm wouldn't work well because I
> only want to cache a few of the columns from a much larger query, plus there
> are
On Sat, Sep 4, 2010 at 3:28 AM, Stefan Behnel wrote:
> What about adding an intermediate namespace called "cache", so that the new
> operations are available like this:
>
I had been thinking that the lru_cache should be a class (with a dict-like
interface), so it can be used explicitly and not j
Am 04.09.2010 12:06, schrieb Antoine Pitrou:
> On Sat, 04 Sep 2010 11:42:08 +0200
> Éric Araujo wrote:
>> > What about adding an intermediate namespace called "cache", so that the
>> > new
>> > operations are available like this:
>> >
>> > print get_phone_number.cache.hits
>> > get_ph
On Sat, 04 Sep 2010 11:42:08 +0200
Éric Araujo wrote:
> > What about adding an intermediate namespace called "cache", so that the new
> > operations are available like this:
> >
> > print get_phone_number.cache.hits
> > get_phone_number.cache.clear()
> >
> > ?
> >
> > It's just a lit
> What about adding an intermediate namespace called "cache", so that the new
> operations are available like this:
>
> print get_phone_number.cache.hits
> get_phone_number.cache.clear()
>
> ?
>
> It's just a little more overhead, but I think it reads quite a bit better.
Or we could
Hi,
reading the description of the new LRU cache in the "What's new in 3.2"
document now, I got the impression that the hits/misses attributes and the
.clear() method aren't really well namespaced. When I read
get_phone_number.clear()
it's not very obvious to me what happens, unless I kn
