Considerations for updating and maintaining [Python] language libraries

Start by reading the 9 October 2025 project meeting notes and the linked PyO3 async-runtimes and DustDDS material. Compare maintaining up-python with generating Python bindings for up-rust, then document the preferred direction and collect relevant information and discussion in this 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.