task(underscore_args): match st.cache_data for underscore-prefixed arguments - #3
Merged
Conversation
…guments An argument whose parameter name starts with an underscore was only kept out of the cache key when the caller passed it by keyword. _entry_key filtered kwargs by name and hashed the args tuple whole, and a tuple carries no names, so the same argument passed positionally still landed in the key. st.cache_data resolves positional arguments to their parameter names first and skips them either way, which is what the README promises parity with. Resolve positional slots to their parameter names through inspect.signature, once per decorated function rather than per call, and drop the underscore ones before hashing. Slots filled by *args keep being hashed: there is no name there to test. Functions with no introspectable signature fall back to hashing every positional argument. Keying by name rather than by position also means a positional call and a keyword call with the same values now reach one entry instead of two. Keyword order stays insensitive, which is a deliberate departure from st.cache_data: it hashes kwargs in caller order, so it treats f(a=1, b=2) and f(b=2, a=1) as separate entries. Sorting by name is the better behaviour and two existing tests already cover it. The key payload changed, so entries written by 0.1.0 are orphaned on upgrade. Ones with a TTL expire and get swept as usual; ttl=None entries are never swept and need clear(). Minor version bump for that.
Runs ruff and the pytest suite with coverage on every branch push, on pull requests and on manual dispatch, across Python 3.12 and 3.13. Mirrors the lint and tests targets in the Makefile. Concurrency group keeps one run per ref, cancelling the run still in flight. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
match st.cache_data for underscore-prefixed arguments
An argument whose parameter name starts with an underscore was only kept out of the cache key when the caller passed it by keyword. _entry_key filtered kwargs by name and hashed the args tuple whole, and a tuple carries no names, so the same argument passed positionally still landed in the key. st.cache_data resolves positional arguments to their parameter names first and skips them either way, which is what the README promises parity with.
Resolve positional slots to their parameter names through inspect.signature, once per decorated function rather than per call, and drop the underscore ones before hashing. Slots filled by *args keep being hashed: there is no name there to test. Functions with no introspectable signature fall back to hashing every positional argument.
Keying by name rather than by position also means a positional call and a keyword call with the same values now reach one entry instead of two.
Keyword order stays insensitive, which is a deliberate departure from st.cache_data: it hashes kwargs in caller order, so it treats f(a=1, b=2) and f(b=2, a=1) as separate entries. Sorting by name is the better behaviour and two existing tests already cover it.
The key payload changed, so entries written by 0.1.0 are orphaned on upgrade. Ones with a TTL expire and get swept as usual; ttl=None entries are never swept and need clear(). Minor version bump for that.