-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
magicbot: Allow typed feedbacks using return type hints #208
Conversation
This allows using feedbacks to create integer and integer array topics.
54db4fa
to
9c5ea4d
Compare
832e3a9
to
31dc5dd
Compare
@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? |
Hm, okay. Personally I expected this to be an implementation detail hidden away by functions, like how |
bb8e176
to
44ad903
Compare
44ad903
to
ecd8a4c
Compare
from ntcore.types import ValueT | ||
|
||
|
||
class StructSerializable(typing.Protocol): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This protocol probably shouldn't belong here...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably should end up in wpimath, but I don't see why it can't be in two places.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I presume you mean wpiutil? I'll follow up with a PR over there then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given there are tests and it works, this seems fine to me.
Brief testing with some additional |
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.