Moka-py

Latest version: v0.1.16

Safety actively analyzes 722581 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 1 of 9

0.12.11

Added

- Support `Equivalent` trait for the key type `K` of the caches.
([492][gh-pull-0492])

0.12.10

Changed

- Disable the `quanta` feature by default. ([482][gh-pull-0482])
- Replaced most uses of `quanta::Instant` with `std::time::Instant` to increase the
accuracy of time measurements ([481][gh-pull-0481]):
- When `quanta` feature is enabled, `quanta::Instant` is used for some
performance critical parts in the cache, and `std::time::Instant` is used for
the rest of the parts.
- However, as of this version, enabling the `quanta` feature will not make any
noticeable difference in the performance.
- When `quanta` feature is disabled (default), `std::time::Instant` is used for
all time measurements.
- Switched to `AtomicU64` of the `portable-atomic` crate, which provides fallback
implementations for platforms where `std` `AtomicU64` is not available
([480][gh-pull-0480]):
- `moka`'s `atomic64` feature no longer has any effect on the build as
`AtomicU64` is now always available on all platforms. But we keep the
`atomic64` feature in `Cargo.toml` for backward compatibility.

0.12.9

Bumped the minimum supported Rust version (MSRV) to 1.70 (June 1, 2023)
([474][gh-pull-0474]).

Fixed

- Prevent an occasional panic in an internal `to_std_instant` method when per-entry
expiration policy is used. ([472][gh-issue-0472])
- Documentation: Removed leftover mentions of background threads.
([464][gh-issue-0464])
- Also added the implementation details chapter to the crate top-level
documentation to explain some internal behavior of the cache.

Added

- Added `and_try_compute_if_nobody_else` method to `future::Cache`'s `entry` API.
([460][gh-pull-0460], by [xuehaonan27][gh-xuehaonan27])

Removed

- Removed `triomphe` crate from the dependency by adding our own internal `Arc` type.
([456][gh-pull-0456])
- Our `Arc` will be more memory efficient than `std::sync::Arc` or
`triomphe::Arc` on 64-bit platforms as it uses a single `AtomicU32` counter.
- Removed needless traits along with `async-trait` usage. ([445][gh-pull-0445], by
[Swatinem][gh-Swatinem])

Changed

- Enable `atomic64` feature only when target supports `AtomicU64`.
([466][gh-pull-0466], by [zonyitoo][gh-zonyitoo])
- Made `once_cell` dependency optional ([444][gh-pull-0444]).
- Stopped creating references unnecessarily to compare pointers by-address.
([452][gh-pull-0452], by [JoJoDeveloping][gh-JoJoDeveloping])

0.12.8

Fixed

- Avoid to use recent versions (`v0.1.12` or newer) of `triomphe` crate to keep our
MSRV (Minimum Supported Rust Version) at Rust 1.65
([426][gh-pull-0426], by [eaufavor][gh-eaufavor]).
- `triomphev0.1.12` requires Rust 1.76 or newer, so it will not compile with our
MSRV.
- docs: Fix per-entry expiration policy documentation ([421][gh-pull-0421], by
[arcstur][gh-arcstur]).

0.12.7

Changed

- Ensure a single call to `run_pending_tasks` to evict as many entries as possible
from the cache ([417][gh-pull-0417]).

0.12.6

Fixed

- Fixed a bug in `future::Cache` that pending `run_pending_tasks` calls may cause
infinite busy loop in an internal `schedule_write_op` method
([412][gh-issue-0412]):
- This bug was introduced in `v0.12.0` when the background threads were removed
from `future::Cache`.
- This bug can occur when `run_pending_task` method is called by user code while
cache is receiving a very high number of concurrent cache write operations.
(e.g. `insert`, `get_with`, `invalidate` etc.)
- When it occurs, the `schedule_write_op` method will be spinning in a busy loop
forever, causing high CPU usage and all other async tasks to be starved.

Changed

- Upgraded `async-lock` crate used by `future::Cache` from `v2.4` to the latest
`v3.3`.

Page 1 of 9

© 2025 Safety CLI Cybersecurity Inc. All Rights Reserved.