Thanks Jim for driving this work. Provide Python client on Rust binding is nice idea. Some comments on the Python api design:
1: In LogScanner, there're two methods with same name, def scan_earliest(self, end_timestamp: long) -> ScanResult:, def scan_earliest(self) -> ScanResult: But IIUC, python doesn't support method override, so two methods with same name but different parameters won't work. 2: I'd suggest to rename `pollBatch` in BatchScanner to `poll_batch` to align the naming style. Best regards, Yuxia ----- 原始邮件 ----- 发件人: "Jark Wu" <[email protected]> 收件人: "dev" <[email protected]> 发送时间: 星期二, 2025年 8 月 12日 上午 11:32:53 主题: [SPAM]Re: [DISCUSS] FIP-11: Fluss Python binding on Fluss Rust Thanks Jim for proposing the python and rust client. The overall design looks good to me. +1 for Rust bindings (via PyO3 or similar) over solutions like Py4J or a separate Python-native implementation. This aligns with the current industry standard for high-performance Python integrations, like Lance, Iceberg, and DeltaLake. Leveraging Rust bindings will not only deliver better performance but also allow us to maximize code reuse from the existing Rust client, reducing maintenance overhead and ensuring consistency across language interfaces. Regarding the FIP, I have some following comments: 1. Could you clarify the intended scope of this FIP? Specifically, does it include integration with PyArrow, Pandas, and DuckDB? The example shows DuckDB integration, but it’s also listed under Future Work. 2. What's the semantics of AppendWriter#write_arrow? Is it a blocking API or a non-blocking API? If it is a non-blocking API, can we have something like Java CompletableFuture as the return type to allow users when the call is successful? 3. What's the behavior of LogScanner#scan_earliest? Does it load all data into client memory upfront and return a fully materialized ScanResult, or does it support streaming semantics, fetching data incrementally to reduce memory pressure? 4. What's the interface of `fluss.Config`? The config = fluss.Config(" 127.0.0.1:9123", 30) in the example confuses me about what the parameters mean? Best, Jark On Fri, 8 Aug 2025 at 20:03, Jim Hu <[email protected]> wrote: > Hi Fluss community, > I’d like to kick off the public discussion on FIP-11¹, which proposes a > thin PyO3 wrapper around the existing Rust client so that Python users can > read/write Fluss without spinning up a JVM. > > - Goal: Java-SDK parity (streaming & batch reads/writes, DDL, point > queries) but 100 % Pythonic. > - Implementation: PyO3 bridge compiled to a native .so/.pyd; zero-copy, > lock-free, no sockets, no JVM start-up cost. > - Repository: fluss-rust/bindings/python. > > I’ve prototyped a minimal PoC at naivedogger/Fluss-Python-Client at > python-client > <https://github.com/naivedogger/Fluss-Python-Client/tree/python-client> > Looking forward to your thoughts. > Best regards, > Jim > [1] > > https://cwiki.apache.org/confluence/display/FLUSS/FIP-11%3A+Fluss+Python+binding+on+Fluss+Rust >
