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

User-defined, struct-backed types that travel between workers by reference

Đang mở
  • Có gì không ổn?
#33 0 bình luận 0 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
28/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Ít trao đổi
Công nghệ
python
Lĩnh vực
distributed-systems

Hướng nghiên cứu

Bắt đầu bằng cách đọc phần khảo sát thiết kế hiện có và prototype chỉ dùng Python có thể chạy được, sau đó so sánh lõi dữ liệu và giao thức trích xuất của nó với các pattern Matrix và proto-Region hiện tại. Phần triển khai cần hỗ trợ các bản ghi cố định do người dùng định nghĩa, việc chuyển giao tham chiếu giữa các worker, các lỗi do handle cũ và cơ chế fallback bằng cách sao chép, đồng thời giữ nguyên các class và method do người dùng sở hữu.

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

Mô tả

design

Problem

bocpy lets you put data in a Cown and hand it to behaviors running on
worker sub-interpreters. Today that data crosses the interpreter boundary by
being pickled and copied — which is fine for ordinary Python objects, but
leaves a gap for users who want a small, fixed-shape record (a particle, a
pixel, a quote, a sensor reading) to move between workers cheaply and by
reference, the way Matrix already does.

Right now, getting that requires writing a C extension against the public ABI.
That is a high bar for a Python programmer who simply wants a typed struct
with a handful of numeric fields. We have a proto-Region pattern that makes
native types safe to share across interpreters, but no on-ramp to it that
stays entirely in Python.

User need

A Python programmer should be able to define their own type — a normal
class, with their own methods and their own place in their own class
hierarchy — give it a struct-shaped data core, and have instances of it move
between workers without a copy and without writing any C. Crucially, bocpy
should not dictate how they structure or package that type.

The access-safety guarantees that make this sound (only one interpreter may
touch the data at a time; a stale handle left behind after a handoff cannot
read or corrupt the data) must hold automatically, without the user having to
reason about interpreters or ownership.

What a solution should be able to do

  • Let a user describe a fixed record of struct-packable fields (ints, floats,
    fixed-width bytes) using only the standard library, no C.
  • Ship one such record between workers by reference when possible, falling
    back to a copy only when a copy is genuinely unavoidable.
  • Enforce single-owner access discipline at the boundary, so reads/writes from
    the wrong interpreter fail loudly rather than silently racing.
  • Impose no base class on the user. They opt in by exposing a small hook
    on their own type, and they keep full control of their methods and class
    layout.
  • Make ordinary editor intellisense "just work" for the user's fields, on both
    the producing and consuming side, without bocpy-specific ceremony.
  • Leave it entirely to the user whether (and how) to reattach their own
    methods to data received in a worker — bocpy moves the data, the user owns
    the business logic.

Explicitly out of scope (for a first cut)

  • Variable-length, resizable, or nested records.
  • Arbitrary Python object fields or embedded cowns.
  • Zero-copy live views (buffer protocol) into the shared data.
  • The full region model (nesting, freeze, merge, borrow tracking).

Notes

A design exploration and a runnable Python-only prototype already exist and
validate the core concept — a small shippable data core, a one-method
extraction protocol, and automatic single-owner enforcement — including the
cross-interpreter handoff and the stale-handle failure mode. This issue tracks
turning that concept into a real feature; the detailed design will be linked
separately.

Ngôn ngữ chính
Python
Star
201
Fork
10
Không có pull request nào được merge trong 30 ngày

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 microsoft/bocpy

Tất cả issue của microsoft/bocpy

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.