Considerations for updating and maintaining [Python] language libraries

首先阅读 2025 年 10 月 9 日的项目会议记录，以及链接的 PyO3 async-runtimes 和 DustDDS 材料。比较维护 up-python 与为 up-rust 生成 Python bindings，然后记录首选方向，并在此 issue 中收集相关信息和讨论。

The overall structure of the uProtocol ecosystem has so far been built on the availability and continually improving quality of the core uProtocol specification, which are then implemented in 'language libraries' (e.g. up-python) and transport-protocol adapters (e.g. up-python-mqtt') for each programming language environment that the project is supporting. This approach is what the project started with, with the understanding that a uProtocol tck exists to validated compliance and interoperability of the different implementations.

There is a valid question raised about, instead of (not) maintaining specific language (e.g. Python) language libraries, we might be better off using something like https://crates.io/crates/pyo3 to (periodically) create/update Python bindings for up-rust (which at this point is probably the reference implementation of the spec).

This issue is to provide a discussion marker for this topic, specifically for how to best evolve/revive up-python. The topic has been initially discussed in the uProtocol project meeting on 9th October 2025.

Some links for potential inspiration of a binding-to-up-rust approach, informed by the DustDDS project kindly participating in that session and providing some insights on how they approached that exact challenge:

• see https://github.com/PyO3/pyo3-async-runtimes for wrapping Rust APIs
• used for implementing Rust => Python bindings for DustDDS
• DustDDS approach: do standalone API code in Python (front-end language), to be free build something that completely idiomatic for that language, then link that API to generated bindings to Rust crate. This allows both libraries to live entirely in their respective worlds, and adhere to the appropriate design practices.
• Always recommend it if possible to not put any business logic on this the binding layer => refer to DustDDS for how this could be done, also wrt generating Documentation for the front-end language (e.g. Python) from the core library/crate (Rust)

Some more discussion items can be found in the minutes of abovementioned meeting - pls treat this issue as a place for further discussing this and collecting pertinent information.