Message183913
Raymond's plan sounds good to me.
We may also want to tweak the 3.3 lru_cache docs to note the trade-offs involved in using it. Perhaps something like:
"As a general purpose cache, lru_cache needs to be quite pessimistic in deriving non-conflicting keys from the supplied arguments. When caching the results of CPU-bound calculations, the cost of deriving non-conflicting keys may need be assessed against the typical cost of the underlying calculation."
Which does give me a thought - perhaps lru_cache in 3.4 could accept a "key" argument that is called as "key(*args, **kwds)" to derive the cache key? (that would be a separate issue, of course) |
|
Date |
User |
Action |
Args |
2013-03-11 02:21:38 | ncoghlan | set | recipients:
+ ncoghlan, barry, brett.cannon, rhettinger, terry.reedy, jcea, pitrou, pjenvey, ezio.melotti, zzzeek, asvetlov, sbt, serhiy.storchaka, bdkearns |
2013-03-11 02:21:38 | ncoghlan | set | messageid: <1362968498.55.0.2707895034.issue16389@psf.upfronthosting.co.za> |
2013-03-11 02:21:38 | ncoghlan | link | issue16389 messages |
2013-03-11 02:21:37 | ncoghlan | create | |
|