Zheaoli commented on code in PR #3514:
URL:
https://github.com/apache/incubator-opendal/pull/3514#discussion_r1386031309
##########
bindings/python/python/opendal/__init__.pyi:
##########
@@ -73,6 +73,7 @@ class AsyncOperator:
async def copy(self, source: str, target: str): ...
async def rename(self, source: str, target: str): ...
async def remove_all(self, path: str): ...
+ def blocking(self) -> Operator: ...
Review Comment:
> Our VISION is to build the best **python** lib to access data freely.
This is what I'm talking about. "keep the same style with the rust core" is
not the goal, but it is a way.
1. In Rust/Java, we have a chain `Operator -> blocking/make_blocking ->
BlockingOperator.` This chain is semantic consensus. But in Python, Our chain
may be `AsyncOperator -> blocking/anything else -> Operator`. It's not
consensus.
2. One of the best practices for Python binding is to keep the same call
convenience style with the lib they want to binding with. For now we meet the
semantic convert issue.
3. About the action impl, IMO, `convert_to_blocking`, `blocking_operator` in
property(with `blocking_opertator` and `getter` in Rust side) are both
acceptable way
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
