[BUG-ish]: Python's duck typing hides a loud C++ API break

[gerth2]

Problem description

2024: https://robotpy.readthedocs.io/projects/robotpy/en/2024.3.2.1/wpimath.controller/SimpleMotorFeedforwardMeters.html#wpimath.controller.SimpleMotorFeedforwardMeters.calculate

calculate(curVel, curAccel)

versus

2025: https://robotpy.readthedocs.io/projects/robotpy/en/stable/wpimath.controller/SimpleMotorFeedforwardMeters.html#wpimath.controller.SimpleMotorFeedforwardMeters.calculate

calculate(curVel, nextVel)

Here's where we got burned:

https://github.com/RobotCasserole1736/RobotCasserole2025/blob/902ba40f83ad67a8f2dd23db6c10b35afdf920c9/drivetrain/swerveModuleControl.py#L202

The change in API is mentioned (indirectly-ish) in the wpilib 2025 change notes (and shows up in the doc text for that function), so we were able to find it within ~30 minutes of debug.

However, per a quick chat with Peter, this is maybe something to consider, since the API break relied on C++'s units implementation, which is currently collapsed away in python.

I'm not sure what exactly could be done to help catch this in python in future years (typehinting checks?), but I also haven't thought about it a ton. I will do some more thinking/asking around, and make some comments if I have ideas.

Operating System

Windows

Installed Python Packages

N/A

Reproducible example code

See links above.

[auscompgeek]

Hmm. It might be good for next year to make all the units names typing.NewTypes, so a type checker (e.g. mypy, pyright) is able to highlight mismatching units at development time.

[virtuald]

The other way to catch this sort of thing is to write unit tests that cover all the APIs, but that's fairly unrealistic at this point I think.

[PeterJohnson]

For this year it feels prudent to rename the function like what we did in Java? I’m a bit hesitant about requiring units in the wrappers as that’s likely going to be difficult to deal with in Blockly / beginner Python users?

[virtuald]

To be consistent we'd have to rename anything that has units in it to something different -- and have it be some automated thing that way if the unit changes then the function name changes too.

We could consider such a thing for 2027, but tbh that doesn't sound great to me to do it everywhere, and if we did it manually then we could still run into this issue.

Elsewhere in RobotPy we use the default names and the default units for most functions, and when we add different unit overloads then we name them (which is usually something like fromFeet et al).