You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/native_backend_unification.md
+23Lines changed: 23 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,6 +10,20 @@ The important user-facing contract is simple:
10
10
- the same Python calls should work with and without `optv` installed
11
11
- native acceleration is an implementation detail, not a second API surface
12
12
13
+
## Implementation Checklist
14
+
15
+
Use this checklist when adding or changing backend routing:
16
+
17
+
-[ ] Import backend-facing symbols from `pyptv._backend`, not directly from `optv` or `openptv_python`, in pipeline code.
18
+
-[ ] Ensure the active engine is selected through `_native_compat.set_engine()` and queried through `should_use_native(...)` or the backend helper functions.
19
+
-[ ] When `optv` is installed and selected, use the native module objects and native parameter/calibration classes.
20
+
-[ ] When `optv` is missing or disabled, keep the Python/Numba fallback path callable with the same function signatures.
21
+
-[ ] Convert Python objects to native objects at backend boundaries only; do not leak backend-specific types into unrelated code paths.
22
+
-[ ] Convert native objects back to Python objects only when a downstream caller still expects the Python implementation model.
23
+
-[ ] Preserve input and output shapes between backends for detection, correspondences, calibration, reconstruction, and tracking.
24
+
-[ ] Keep a fallback path for calibration routines that fail in the native backend, but make sure the fallback sees the same data model as the native path.
25
+
-[ ] Add or update tests whenever a backend boundary changes so the native and Python paths stay behaviorally aligned.
26
+
13
27
The runtime flow is:
14
28
15
29
| Layer | Responsibility |
@@ -94,6 +108,15 @@ The important distinction is not whether a native implementation exists. It is
94
108
whether the normal `openptv_python` runtime path already chooses that native
95
109
implementation transparently for the user.
96
110
111
+
### Contract Rules
112
+
113
+
-`pyptv._backend` is the only layer that should decide which implementation is active.
114
+
- Public helpers must keep one stable signature, regardless of backend.
115
+
- Backend-specific object construction must stay inside conversion helpers or backend dispatch code.
116
+
- If a native routine expects a native object type, the wrapper must build it before the call.
117
+
- If a fallback routine expects Python dataclasses, the wrapper must convert back before the call.
118
+
- A failed native path may fall back to Python, but only after restoring or rebuilding the input objects the fallback expects.
0 commit comments