Skip to content
This repository has been archived by the owner on Nov 5, 2023. It is now read-only.

[BUG]: Type hints in .pyi don't resolve all units #29

Closed
TheTripleV opened this issue Apr 3, 2022 · 2 comments
Closed

[BUG]: Type hints in .pyi don't resolve all units #29

TheTripleV opened this issue Apr 3, 2022 · 2 comments

Comments

@TheTripleV
Copy link
Member

Problem description

When type hints are generated, units are not properly resolved:
From robotpy-pathplannerlib:

class PathPlannerTrajectory():
    class PathPlannerState():
        def __init__(self) -> None: ...
        def interpolate(self, endVal: PathPlannerTrajectory.PathPlannerState, t: float) -> PathPlannerTrajectory.PathPlannerState: ...
        @property
        def acceleration(self) -> meters_per_second_squared:
            """
            :type: meters_per_second_squared
            """
        @property
        def angularAccel(self) -> units::unit_t<units::unit<std::__1::ratio<1l, 1l>, units::base_unit<std::__1::ratio<0l, 1l>, std::__1::ratio<0l, 1l>, std::__1::ratio<-2l, 1l>, std::__1::ratio<1l, 1l>, std::__1::ratio<0l, 1l>, std::__1::ratio<0l, 1l>, std::__1::ratio<0l, 1l>, std::__1::ratio<0l, 1l>, std::__1::ratio<0l, 1l> >, std::__1::ratio<0l, 1l>, std::__1::ratio<0l, 1l> >, double, units::linear_scale>:
            """
            :type: units::unit_t<units::unit<std::__1::ratio<1l, 1l>, units::base_unit<std::__1::ratio<0l, 1l>, std::__1::ratio<0l, 1l>, std::__1::ratio<-2l, 1l>, std::__1::ratio<1l, 1l>, std::__1::ratio<0l, 1l>, std::__1::ratio<0l, 1l>, std::__1::ratio<0l, 1l>, std::__1::ratio<0l, 1l>, std::__1::ratio<0l, 1l> >, std::__1::ratio<0l, 1l>, std::__1::ratio<0l, 1l> >, double, units::linear_scale>
            """
        @property
        def angularVel(self) -> radians_per_second:
            """
            :type: radians_per_second
            """
        @property
        def curveRadius(self) -> meters:
            """
            :type: meters
            """

Some types are left in C++ syntax (units::unit_t<units::unit<std::__1::ratio<1l, 1l>...) and others are simplified but not imported so they are not valid (meters).

robotpy-photonvision has the same issue.

Operating System

MacOS

Installed Python Packages

No response

Reproducible example code

No response

@auscompgeek
Copy link
Member

I'm too lazy to move this issue, but it looks like robotpy-wpimath is missing a type caster for units/angular_acceleration.h (among a few other of the units headers). If we throw one in then we should get back out valid syntax.

On the undefined type aliases, yeah, it's definitely an issue, and I'm surprised nobody's raised it yet. mypy will treat them as Any when you import them (which is mostly fine), but I have noticed Pyright/Pylance will also show Any in VSCode. jedi-language-server returns the unresolved types though. Ideally we'd have meters: TypeAlias = float somewhere. I don't think we have a way of injecting things into the type stub output yet.

@virtuald virtuald transferred this issue from robotpy/robotpy-build Apr 3, 2022
@virtuald
Copy link
Member

virtuald commented Apr 3, 2022

Ideally we'd have meters: TypeAlias = float somewhere. I don't think we have a way of injecting things into the type stub output yet.

This would be the right way to fix it... but sounds like work. IMO it's better to have the names in there (and have the type hints be invalid) than to not have the names, since the units aren't always obvious.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants