[issue9396] Standardise (and publish?) cache handling in standard library

[Éric Araujo]

Éric Araujo  added the comment:

Raymond, out of curiosity, can you tell why you removed lfu_cache?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9396] Standardise (and publish?) cache handling in standard library

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9396] Standardise (and publish?) cache handling in standard library

[Nick Coghlan]

Nick Coghlan  added the comment:

Have we had any luck getting this to play nicely with the buildbots yet? (I 
lost track of where the last checkin got to). The necessary Modules/Setup 
change to adjust when _collections is built should have propagated through by 
now.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9396] Standardise (and publish?) cache handling in standard library

[Éric Araujo]

Éric Araujo  added the comment:

After discussion with RDM on IRC, I’m opening a new report to track this 
feature request separately. (It’s also a dependency of this bug.)

--
assignee: r.david.murray -> rhettinger
dependencies: +Add attribute pointing to wrapped function to partial objects

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9396] Standardise (and publish?) cache handling in standard library

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Great minds think alike.  I was just about to propose that functools.wraps add 
a standard attribute to point at the underlying function (on the theory that 
objects should be introspectable).  This would allow a standard way to get to 
the underlying unwrapped functions.

--
assignee: rhettinger -> r.david.murray
nosy: +r.david.murray
priority: normal -> low
resolution: fixed -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9396] Standardise (and publish?) cache handling in standard library

[Nick Coghlan]

Nick Coghlan  added the comment:

On Mon, Aug 9, 2010 at 3:11 PM, Raymond Hettinger
 wrote:
> ISTM, we should just provide basic caching with reasonable space consumption 
> (i.e. not huge) that gives improvements to common use cases (like I've done 
> with the fnmatch and re module) and let programmers with unusual cases add 
> their own caching options rather that be tied into our choice of lru vs lfu 
> or whatnot.

A very good point! Perhaps we should note that somewhere? I'm not sure
where though, unless we just mention it in the docs for the relevant
modules..

Going the other way (using a smaller, or no, cache), perhaps in
addition to the new hit/miss attributes, the cache decorators should
expose the original function to allow the cache to be bypassed?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9396] Standardise (and publish?) cache handling in standard library

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I was thinking about the problem of developers wanting a different cache size 
than that provided in standard lib modules. 

ISTM that now we've offered caching abilities in functools, a developer can 
easily add another layer of cache around any API they are interested in.  For 
example, if someone is using thousands of recurring fnmatch patterns, they can 
write something like:

   @functools.lfu_cache(maxsize=1)  # custom fat cache
   def fnmatchcase(*args):
   return fnmatch.fnmatchcase(*args)

IMO, this beats adding caching controls to lots of APIs that should be focused 
only on their problem domain.  IOW, it is probably not a good idea to add 
purge() and cache_resize() functions to multiple modules throughout the 
standard lib.

ISTM, we should just provide basic caching with reasonable space consumption 
(i.e. not huge) that gives improvements to common use cases (like I've done 
with the fnmatch and re module) and let programmers with unusual cases add 
their own caching options rather that be tied into our choice of lru vs lfu or 
whatnot.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9396] Standardise (and publish?) cache handling in standard library

[Nick Coghlan]

Nick Coghlan  added the comment:

On Mon, Aug 9, 2010 at 2:29 PM, Raymond Hettinger
 wrote:
> I did find a simple way to dynamically resize the maxcache, but did not apply 
> it yet.   Will look at more applications to see if it is really needed.
>
> Nick, thanks for the great ideas.  These changes simplified the code where 
> they were applied and resulted in a smarter caching strategy.

The reason I mentioned the dynamic sizing specifically was that the
discussions where we realised we had all these different caches
floating around had to do with tuning the caching strategy to a
particular application based on speed vs memory trade-offs. While we
can pick a number that is a reasonable default, a server deployment
may want to turn the dial towards faster response times with higher
memory consumption, while an embedded device may want to push the dial
the other way. The smarter caching strategies you added are likely to
help far more than the blunt hammer approach of increasing the cache
size, but the speed/memory trade-off in choosing that size is still a
question that has no universally correct answer.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9396] Standardise (and publish?) cache handling in standard library

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Applied the lru_cache() to fnmatch and re.
See r83874 r83871.

I did find a simple way to dynamically resize the maxcache, but did not apply 
it yet.   Will look at more applications to see if it is really needed.

Nick, thanks for the great ideas.  These changes simplified the code where they 
were applied and resulted in a smarter caching strategy.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9396] Standardise (and publish?) cache handling in standard library

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +merwok

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9396] Standardise (and publish?) cache handling in standard library

[Nick Coghlan]

Nick Coghlan  added the comment:

Yeah, I'm not sure the dynamic resizing makes sense in general. I was just 
pointing it out as something supported by the existing caches that could 
complicate a consolidation effort.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9396] Standardise (and publish?) cache handling in standard library

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9396] Standardise (and publish?) cache handling in standard library

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I will take a look at the various caches and see if some of their features can 
be consolidated.  It is okay if some need to have their own strategies or 
situation specific approaches, but you're right that common features should be 
looked at to see if they make sense in the functools caches.

Am not sure that dynamically changing the maxsize is a generally useful feature 
(most are set to the largest size that makes sense and not revisited latter), 
but I will take a look to whether that complicates the code (if it's simple and 
fast, it may be worth doing).

--
versions: +Python 3.2 -Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9396] Standardise (and publish?) cache handling in standard library

[Nick Coghlan]

Nick Coghlan  added the comment:

With Raymond adding functools.lru_cache and functools.lfu_cache, it should be 
possible to use those for the various caches in the standard library.

My only point of concern is that the standard lib caches tend to allow dynamic 
modification of the max cache size, while the new cache decorators appear to be 
fixed at the size specified when defining the decorator.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9396] Standardise (and publish?) cache handling in standard library

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9396] Standardise (and publish?) cache handling in standard library

[Florent Xicluna]

Changes by Florent Xicluna :


--
nosy: +flox

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9396] Standardise (and publish?) cache handling in standard library

[Nick Coghlan]

New submission from Nick Coghlan :

The standard library has several cache implementations (e.g. in re, fnmatch and 
ElementTree) with different cache size limiting strategies. These should be 
standardised and possibly even exposed for general use.

Refer to python-dev discussion:
http://mail.python.org/pipermail/python-dev/2010-July/102473.html

--
components: Library (Lib)
messages: 111790
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Standardise (and publish?) cache handling in standard library
type: feature request
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com