Kyle Barron

I don't think that's possible in the Parquet spec. The metadata in the Parquet spec references byte ranges into the original file, and if you only have the bytes of...

> tables without dictionary-encoded columns, it seems to work. I was thinking dictionary-encoded columns might be stored elsewhere in the Parquet file. That said, I really don't think this is...

What does this gain over the existing `File` / `Blob` support?

We can expose [this trait](https://docs.rs/parquet/latest/parquet/arrow/async_reader/trait.AsyncFileReader.html), which is essentially what you want. An initial implementation would expose just the range request interface, then later we could add support for cached metadata,...

Looks like the error is hitting https://github.com/nmandery/h3ronpy/issues/77

Thanks! Would you be able to add a JS test that failed before this change but passes after it? I figure just passing a column projection into a read function...

FWIW the [`obstore.Bytes`](https://developmentseed.org/obstore/latest/api/get/#obstore.Bytes) type allows externally-allocated memory via the buffer protocol (and via [`pyo3-bytes`](https://docs.rs/pyo3-bytes/latest/pyo3_bytes/)) and is slowly progressing to support all the methods on `bytes`. We could probably mix and...

> Does it inherit from Bytes too? You mean subclass? That's not possible because it doesn't use `builtins.bytes` internally. But it can match the `bytes` methods as a protocol as...

I think that's a valid choice for downstream users but not something that `obstore.Bytes` should implement itself.

Also fwiw `cramjam.Buffer` adds support for a _writable_ file-like BytesIO object in Rust-allocated memory, but I just realized that if you only need a _readable_ file-like BytesIO object, you can...