Closed auscompgeek closed 1 month ago
@virtuald I mostly want to check, is checking hasattr WPIStruct the intended way to check whether a type can be used as a struct topic/log type?
Yes that is the intent, https://github.com/robotpy/mostrobotpy/blob/main/subprojects/robotpy-wpiutil/wpiutil/wpistruct/dataclass.py#L130 does that, and https://github.com/robotpy/mostrobotpy/blob/868f50a724399cfdb3cc45b0067bbb20e9e7e401/subprojects/robotpy-wpiutil/wpiutil/src/wpistruct/wpystruct.h#L230
Hm, okay. Personally I expected this to be an implementation detail hidden away by functions, like how dataclasses
has is_dataclass
and fields
functions.
Brief testing with some additional @magicbot.feedback
in my team's code uncovered I hadn't handled the case of things like a return type hint of a 4-tuple (of a single type). Accounted for that too with a test.
This inspects the return type hint on
@feedback
methods to determine what topic type they should publish. This allows:setValue
method preferring to upcast integers to doubles),setValue
), andsetValue
always uses the type of the first element).If the types are incompatible at runtime, the robot code will crash, e.g. in tests:
Returning a non-homogeneous tuple will result in the same error message as previously, for example:
To appease type checkers without majorly refactoring the
magic_tunable
module further, this also adds support for int and struct tunables. This fixes the inferred type being wrong fortunable(1)
(it claimed it was an int tunable, when reading it gave floats instead). Tunables with empty array defaults using type hints will be supported in a later PR.I recommend reviewing this PR commit by commit.