Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Considerations for updating and maintaining [Python] language libraries

Đang mở
#64 0 bình luận 2 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
20/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
python, rust
Lĩnh vực
backend-api-design

Hướng nghiên cứu

Bắt đầu bằng việc đọc ghi chú cuộc họp dự án ngày 9 tháng 10 năm 2025 và tài liệu được liên kết về PyO3 async-runtimes và DustDDS. So sánh việc duy trì up-python với việc tạo Python bindings cho up-rust, sau đó ghi lại hướng đi được ưu tiên và tập hợp các thông tin cũng như thảo luận liên quan trong issue này.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

help wanted

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.

Ngôn ngữ chính
Python
Star
3
Fork
13
Merge trung bình
5 giờ 28 phút
Pull request đã merge (30 ngày)
1

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của eclipse-uprotocol/up-python

Tất cả issue của eclipse-uprotocol/up-python

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.