Hi, Yuxia. Thanks for your comments. #1. Good catch! I've consolidated the four legacy scan methods into a single scan(**kw) entry point. By passing different keyword arguments users can obtain all four original behaviors. #2. Thanks for the suggestion.
yuxia <[email protected]> 于2025年8月12日周二 15:12写道： > 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 > > >
