Xuanwo commented on code in PR #3514:
URL:
https://github.com/apache/incubator-opendal/pull/3514#discussion_r1386041798
##########
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:
> 1. But in Python, Our chain may be `AsyncOperator -> blocking/anything
else -> Operator`. It's not consensus.
I don't know what's `consensus` we need to reach. As I said, it's not a goal
to align with rust core.
Python bindings is designed to following the `Operator` & `AsyncOperator`
pattern. We should stick to this. There is no `blocking` concept in our API.
This is I think the `blocking` is not good.
> 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.
No, we are not a binding. Python binding has its own API design.
It's just powered by opendal rust core. Please don't mix up public API and
underlying implementation.
- For public API: we are `opendal` in python. User should not know it's
powered by rust.
- For underlying implementation: we are the python binding of `opendal` in
rust, we need rust core to build.
---
The most confused thing to me is how to design an API that can convert
between `Operator` and `AsyncOperator`. For example, if there is a python lib
that has `Client` and `AsyncClient`, what's the API will be like to convert
between them?
--
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]
