Raymond Hettinger added the comment: A few thoughts:
* The LRU cache was originally intended for IO bound calls not for tight, frequently computationally bound calls like re.compile. * The Py3.3 version of lru_cache() favors size optimizations (i.e. it uses only one dictionary instead of the two used by OrderedDict and keyword arguments are flattened into a single list instead of a nested structure). Also, the 3.3 version assures that __hash__ is not called more than one for a given key (this change helps objects that have a slow hash function and it helps solve a reentrancy problem with recursive cached function calls). The cost of these changes is that _make_key is slower than it was before. * I had hoped to get in a C version of _make_key before Py3.3 went out but I didn't have time. Going forward, the lru_cache() will likely have a C-implementation that is blindingly fast. * For the re module, it might make sense to return to custom logic in the re modue that implements size limited caching without the overhead of 1) LRU logic, 2) general purpose argument handling, 3) reentrancy or locking logic, and 4) without statistics tracking. ---------- assignee: -> rhettinger _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16389> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
