opendal
opendal copied to clipboard
Add more file-like methods to the python bindings
This adds the following methods to the File type in the Python bindings:
flushreadablewritableseekableclosedreadinto
For AsyncFile, the following were added:
readablewritableseekableclosed
Manually testing was done locally, but I couldn't get the unit tests to run due to environment dependency issues. Hopefully CI will trigger here.
This partially addresses #4384. It assumes that all readable services support seeking, which may not be valid, but it mirrors the implementation seek.
It assumes that all readable services support seeking
Can you use https://docs.rs/opendal/latest/opendal/struct.Capability.html#structfield.read_can_seek?
This is an ongoing RFC related to this: https://github.com/apache/opendal/pull/4382
I've added the capability check to the Python bindings, but is there anything specific I should do w.r.t. the RFC? Or is it just a blocker for this PR?
Or is it just a blocker for this PR?
After this RFC been implemented (which is already going on), we might need to change the way of implement File in python.
Hi, @mobiusklein, sorry for the long waiting. I feel like this PR is good to go. Would you like to fix the CI issues so we can get it merged?
Is it correct to say that seek operations are now supported universally since the behavior is no longer described by the Capability type? I don't see any documentation about it except for an outdated note in https://opendal.apache.org/docs/rust/opendal/struct.Capability.html#naming-style.
Is it correct to say that
seekoperations are now supported universally since the behavior is no longer described by theCapabilitytype?
Yes!
Thank you. I've refactored the bindings to reflect that. The Capability struct the File types carry around now probably is no longer relevant but I left it there for the future. I'll have to re-digest what the capabilities mean but on my first pass I don't see a way they'd intrude into the Python API.
Things appear to be all set now. Thank you.