Only support tuple[int, int] for ByteRangeRequests

[maxrjones]

I don't think there should be two different ways to specify "the beginning of the buffer".

this also holds for zarr-python -- I think we currently use None and 0 to express the same thing, which should be fixed.

Originally posted by @d-v-b in #1661 (comment)

Based on this discussion, None should not be supported as the start or end for ByteRangeRequests.

[maxrjones]

I would be glad to work on this if helpful.

[d-v-b]

thanks for opening this issue! I think always using a non-negative int for the start of a byte range will work, but I'm not sure about the end -- I suspect None might be necessary to model an unknown size. Someone who knows the stores better than I do (cc @normanrz ) would have a better idea here.

[maxrjones]

I think always using a non-negative int for the start of a byte range will work, but I'm not sure about the end -- I suspect None might be necessary to model an unknown size.

Ah, this actually brings up a third scenario which might also motivate typing of tuple[int, int | None]. The ObjectStore PR supports a suffix request with the length indicated by a negative start value. Local store seems to support this as well, with an additional possibility of a negative end value. So in both cases negative values indicate the number of bytes from the end of the file. FsspecStore does not seem to support this.

I was really surprised to discover ByteRangeRequest is actually [start, length] rather than [start, end] given the typical structure of range headers. I think this will need to be very prominently documented for potential extensions (e.g., as far as I can tell #1661 was written assuming ByteRangeRequest represents [start, end]).

[d-v-b]

We should minimize surprises here, so I would support normalizing our byte range convention to match what people expect

[maxrjones]

Darn, I'm sorry that I missed that this is a duplicate of #2437. Let's continue any discussion there.