Raymond Hettinger <raymond.hettin...@gmail.com> added the comment:
> I am not sure about an addition _PyDict_GetItem_KnownHash(). It is a necessary check. The user call is allowed to update the cache so we no longer know without checking whether the new key/result pair has already been added. That is in fact the main bug that is being fixed. > Every of dict operations can cause executing an arbitrary code > and re-entering the execution of bounded_lru_cache_wrapper(). FWIW, the new _PyDict_GetItem_KnownHash() call is made at the top of the post user call code path, before any modifications of the cache have occurred. This is the safest possible time to allow reentry. There's really nothing this call can do that couldn't have happened in the user function call. Also, only the normal case (where the key is not present) proceeds to modify the cache state. The other two paths exit immediately. > Could not the API that atomically checks and updates the dict > (like getdefault()/setdefault()) be useful here? That seems tempting but our goal is a "contains" test. We're not storing a new entry at this point. Instead, we're just checking to see if any further work is necessary. At some point in the future (not in this bug fix), we could further sync the C code and pure python code to use the rotating root entry. That means that in the "self->full" path, we never need to extract, append, or prepend links. Only the value fields and root pointer need to be updated. That does less work and always leaves the structure in a consistent state. > Currently the C implementation memoizes only one result, and > f(1.0) returns 1. With the Python implementation and with > the proposed changes it will return 1.0. When keyword argument sorting was dropped, we gained a speed improvement but came to treat f(a=1, b=2) and f(b=2, a=1) as distinct calls. Here we cut memory overhead in half for common cases but will treat f(1) and f(1.0) as distinct calls. I'm fine with that. It's also nice that the C and pure Python versions now match. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35780> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
