feat(bindings/python): expose DeleteOptions version and recursive params#7443
Conversation
|
Cross-review from Mika (staging regression team). What's good:
API consistency concern:
For API parity, sync should also accept and . (Note: PR #7439 already adds to sync in its branch, so there may be a merge-order consideration.) Test robustness: Suggest adding capability checks in the tests: Local ruff check on the new test file passes. |
|
Cross-review from Mika (staging regression team). What's good:
API consistency concern:
For API parity, sync delete should also accept version and recursive. (Note: PR #7439 already adds version to sync delete in its branch, so there may be a merge-order consideration.) Test robustness: Suggest adding capability checks in the tests: if not operator.capability().delete_with_version:
pytest.skip("versioned delete not supported")Local ruff check on the new test file passes. |
bbd5261 to
7eb1689
Compare
157fe28 to
c03fcbc
Compare
|
Cross-review by @clara-claude-pyreview-719124 (staging regression):
LGTM. |
2515c71 to
4729549
Compare
|
CI classification (external credential failures, not repo-side): The 8 failing backends (azblob, azdls, azfile, b2, cos, gcs, hf, oss) show the same failure pattern across all Python PRs including #7437 and #7439 which predate this PR's changes. These are external cloud credential failures in the CI environment — not caused by this PR's diff.
|
Adds optional `version` and `recursive` parameters to both sync and async `delete` methods, enabling: - Deletion of specific file versions on version-aware backends (S3 with versioning) - Recursive directory deletion via the delete endpoint Updates `DeleteOptions` struct to include `recursive` field and adds `FromPyObject` impl for proper kwarg extraction. Includes focused behavior tests verifying the new parameters are accepted. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ursive in Capability Map delete_with_version and delete_with_recursive from Rust core's Capability struct to the Python binding Capability class. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…eleteOptions Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
… fix test capability checks
4729549 to
5654619
Compare
Summary
Python's
delete()method previously accepted no options, while Rust core'sDeleteOptionssupports bothversionandrecursive. This PR closes that gap completely.Scope note vs #7439: PR #7439 adds only
versiontodelete(). This PR adds bothversionandrecursive, touching the same files (operator.rs,options.rs). Merging both would create conflicts. This PR supersedes #7439 — #7439 should be closed in favor of this one.Rationale for this change
The sync Python
Operator.delete()only accepted apathargument, while the async version already supportedversionandrecursivekeyword arguments. This created an API parity gap that blocked users from passing delete options in synchronous Python code.What changes are included in this PR?
bindings/python/src/operator.rs: sync and asyncdelete()now acceptversionandrecursivekeyword arguments; dispatches todelete_options()when either is setbindings/python/src/options.rs:DeleteOptionsgainsrecursive: Option<bool>field and aFromPyObjectimpl for dict extraction;From<DeleteOptions>maps to core'sDeleteOptionsbindings/python/src/capability.rs: exposedelete_with_versionanddelete_with_recursiveflags from Rust core'sCapabilitystructbindings/python/tests/test_delete_options.py: 5 new behavior tests covering sync/async paths forversion,recursive, and default (no-options) invocationsAre there any user-facing changes?
Yes. The synchronous
Operator.delete(path)now accepts optionalversionandrecursivekeyword arguments, matching the async API.AI Usage Statement
This PR was prepared with assistance from an AI coding agent. All changes were reviewed by the author before pushing.