-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
Fix obscure lru_cache reentrancy bug #73177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Call __len__ directly inside the LRU cache code rather than using len(). This helps further encapsulate the cache internals making it less dependent on parts of the environment that are subject to change. |
Wrapping len() in an lru_cache is bad idea, because this brakes len() of lists, dicts and other non-hashable collections. Should we support this doubtful case? |
It is effortless to make this change and is consistent with all the other efforts taken to to protect against reentrancy, so yes, I think it should be done. It isn't so much that I want this to be a use case, I would just like the implementation to be as sound as reasonably possible so that we don't find the LRU cache to be at heart of some future hard-to-find bug in a complex application. How does the patch look to you? |
It looks ugly, but technically correct. Push it if you like. |
New changeset c23f8614151d by Raymond Hettinger in branch '3.5': |
New changeset 5ec5bfcf0089 by Raymond Hettinger in branch 'default': |
Misc/NEWS
so that it is managed by towncrier #552Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: