We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
get_range
start
end
length
Many libraries use either start/end or offset/length for range requests. We should require these params to be keyword-only params.
Additionally, we should allow length as a named parameter (exclusive with end), for ease of use
This would be a breaking change. Sadly I just released 0.3, so this would require an 0.4.
The text was updated successfully, but these errors were encountered:
FWIW I did not find that there is a significant performance cost to using dataclasses for a range requests in addition to suffix and offset requests in https://github.com/maxrjones/zarr-byterangerequest-microbenchmarks/blob/main/plot-results.ipynb, as long as you use if; then syntax rather than match; case. That was the motivation for moving to only using dataclasses in zarr-developers/zarr-python#2585. Norman suggested this possible design for supporting length as well. It would be simple to run similar tests specifically for obstore if helpful.
obstore
But, requiring kwargs would similarly avoid confusion.
Sorry, something went wrong.
get_ranges
Successfully merging a pull request may close this issue.
Many libraries use either start/end or offset/length for range requests. We should require these params to be keyword-only params.
Additionally, we should allow
length
as a named parameter (exclusive withend
), for ease of useThis would be a breaking change. Sadly I just released 0.3, so this would require an 0.4.
The text was updated successfully, but these errors were encountered: