Considerations for updating and maintaining [Python] language libraries

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](https://docs.google.com/document/d/1PEmYh1qoTuBZtanGGEcMASeogLIG9_0qeSWbuOhXmr8).

Some links for potential inspiration of a binding-to-up-rust approach, informed by the [DustDDS project](https://github.com/s2e-systems/dust-dds) 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.

まず、2025年10月9日のプロジェクト会議の議事録と、リンクされている PyO3 async-runtimes および DustDDS の資料を読んでください。up-python の保守と、up-rust の Python bindings の生成を比較し、そのうえで望ましい方向性を文書化し、関連する情報と議論をこの issue に集めてください。

索引モデルが issue の本文から書いたものです。