[BUG] Setting a field on a wp.struct in Python silently unwraps it to a Python type

[thomasbbrunner]

Bug Description

Assigning a Warp scalar (e.g., wp.uint8) to a struct field unwraps it to a plain Python dtype.

The struct setter in codegen.py calls .value on warp scalars, so wp.uint8(1) becomes int(1). This changes the type of the field and can break downstream comparisons.

This is somewhat related to #905. With that fix, Warp now returns its own types instead of casting them to Python types. Maybe we can do the same for the struct setter?

Of course, this is CPU-only. But still relevant for unittests.

MRE

import warp as wp

STATUS_ACTIVE = wp.uint8(1)

@wp.struct
class MyState:
    status: wp.uint8

s = MyState()
assert type(s.status) == wp.uint8  # OK!

# The setter calls .value on warp scalars, converting wp.uint8(1) to int(1).
s.status = STATUS_ACTIVE
assert type(s.status) == wp.uint8  # AssertionError! Type is now int

System Information

Software
Warp (package): 1.12.0
Warp (core): 1.12.0
warp-clang: 1.12.0 (LLVM 15.0.7)
NumPy: 2.4.2
PyTorch: 2.10.0
Python: 3.11.12 (main, Apr 9 2025, 03:49:53) [Clang 20.1.0 ]
Platform: macOS-26.3.1-arm64-arm-64bit

[shi-eric]

Thanks for reporting this with clear reproduction steps! You're right that the struct field setter in set_primitive_value unwraps the Warp scalar via .value for the ctypes backing store but then stores the unwrapped Python value as the attribute, causing the type to decay.

I've opened #1291 with a fix that re-wraps the value in the declared Warp scalar type before storing it in the Python __dict__. Feel free to try it out and let us know if it resolves your use case.

[thomasbbrunner]

Looking good, many thanks!

[shi-eric]

A fix is now merged into the main branch and will be included in Warp v1.12.1 e093c42