Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9396
___
Éric Araujo mer...@netwok.org added the comment:
Raymond, out of curiosity, can you tell why you removed lfu_cache?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9396
___
Nick Coghlan ncogh...@gmail.com 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.
Raymond Hettinger rhettin...@users.sourceforge.net 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
Éric Araujo mer...@netwok.org 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
Nick Coghlan ncogh...@gmail.com 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
Raymond Hettinger rhettin...@users.sourceforge.net 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
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9396
___
Nick Coghlan ncogh...@gmail.com 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
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +merwok
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9396
___
___
Python-bugs-list mailing
Raymond Hettinger rhettin...@users.sourceforge.net 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,
Nick Coghlan ncogh...@gmail.com added the comment:
On Mon, Aug 9, 2010 at 2:29 PM, Raymond Hettinger
rep...@bugs.python.org 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,
Raymond Hettinger rhettin...@users.sourceforge.net 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
Nick Coghlan ncogh...@gmail.com added the comment:
On Mon, Aug 9, 2010 at 3:11 PM, Raymond Hettinger
rep...@bugs.python.org 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
Changes by Florent Xicluna florent.xicl...@gmail.com:
--
nosy: +flox
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9396
___
___
Python-bugs-list
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9396
___
___
Python-bugs-list mailing
New submission from Nick Coghlan ncogh...@gmail.com:
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
17 matches
Mail list logo
