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)