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
{{ message }}
Repository navigation
Array annotation repr() uses constructor form instead of subscript syntax #1628
Follow-up to #1341. That issue fixed _ArrayAnnotationBase.__repr__() emitting raw <class '...'> paths for the dtype. The dtype now renders as a clean name, but the overall form is still the constructor style rather than the subscript syntax the annotation was written with:
wp.array(dtype=wp.uint32, ndim=4) looks like a call to the wp.array constructor, which builds an actual array rather than an annotation, so it does not round-trip. Calling eval() on that string produces a different kind of object.
Impact
Same mechanism as #1341: Sphinx autodoc renders Return type fields with repr() when autodoc_typehints = "description" is set. A function annotated -> wp.array4d[wp.uint32] documents its return type as wp.array(dtype=wp.uint32, ndim=4), which no longer matches the annotation in the source.
Proposed behavior
Render annotations in their subscript form, so repr() matches the written annotation and round-trips through eval():
Array annotation repr() now uses public subscript syntax rather than constructor syntax. This covers the reported forms:
wp.array4d[wp.uint32]
wp.indexedarray[wp.float32, Literal[3]]
wp.array[wp.float32, Any]
These representations match the source annotations and evaluate back to equivalent annotation objects, so Sphinx autodoc return types no longer resemble wp.array(...) constructor calls.
Public API behavior:
Python scope: existing repr() behavior for wp.array, wp.indexedarray, wp.fabricarray, and wp.indexedfabricarray annotations now uses subscript syntax.
There is no kernel API change.
Test coverage:
Modified warp/tests/test_subscript_types.py::TestSubscriptTypes.test_annotation_repr to verify exact representations, higher-dimensional and Any forms, indexed arrays, public dtype aliases, round-tripping, and fallback names for generic dtypes.
Activity
Render array annotation repr in subscript form
Render array annotation repr in subscript form
shi-eric commentedon Jul 14, 2026
This is addressed by 1110eef.
Array annotation
repr()now uses public subscript syntax rather than constructor syntax. This covers the reported forms:wp.array4d[wp.uint32]wp.indexedarray[wp.float32, Literal[3]]wp.array[wp.float32, Any]These representations match the source annotations and evaluate back to equivalent annotation objects, so Sphinx autodoc return types no longer resemble
wp.array(...)constructor calls.Public API behavior:
repr()behavior forwp.array,wp.indexedarray,wp.fabricarray, andwp.indexedfabricarrayannotations now uses subscript syntax.Test coverage:
warp/tests/test_subscript_types.py::TestSubscriptTypes.test_annotation_reprto verify exact representations, higher-dimensional andAnyforms, indexed arrays, public dtype aliases, round-tripping, and fallback names for generic dtypes.Render array annotation repr in subscript form [NVIDIAGH-1628]
Render array annotation repr in subscript form [NVIDIAGH-1628]