-
-
Couldn't load subscription status.
- Fork 365
Expose LatencyStore as public API #3359
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
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@ ## main #3359 +/- ## ======================================= Coverage 94.54% 94.54% ======================================= Files 78 79 +1 Lines 9423 9427 +4 ======================================= + Hits 8909 8913 +4 Misses 514 514
🚀 New features to boost your workflow:
|
pre-commit is mad about a docstring but otherwise this looks g2g
I'm a bit confused about why this is necessary. It's extremely common for downstream libraries to use functions from the testing modules of libraries (e.g., np.testing.assert_..., xr.testing.assert_...). Why do we need a different approach here? I question whether this change is worth it because putting LatencyStore in the same namespace at the other stores would add confusion for people who just want to use Zarr-Python, not develop downstream libraries.
Why do we need a different approach here? I question whether this change is worth it because putting LatencyStore in the same namespace at the other stores would add confusion for people who just want to use Zarr-Python, not develop downstream libraries.
I actually agree - I think it would make more sense to expose LatencyStore within a zarr.testing.storage namespace. That still requires a PR though (which could be this one), because it's currently in zarr.testing.store, and not documented in the public API docs.
Uh oh!
There was an error while loading. Please reload this page.
Closes ##3358
TODO:
docs/user-guide/*.rstchanges/