Improved typing

[joaoantoniocardoso]

Hi,

I love this library, but it is a bit frustrating to interact with it when trying to use typed Python.

I want to know if there is interest in adding type hints, at least to the API.

As an example, we would change from this:

def forced_response(sys, T=None, U=0., X0=0., transpose=False,
                    interpolate=False, return_x=None, squeeze=None):

to something like this:

from typing import Optional
from numpy.typing import ArrayLike

def forced_response(
    sys: LTI,
    T: Optional[ArrayLike] = None,
    U: Optional[ArrayLike | float | np.floating] = 0.,
    X0: ArrayLike | float | np.floating = 0.,
    transpose=False, interpolate=False,
    return_x: Optional[bool] = None,
    squeeze: Optional[bool] = None
) -> TimeResponseData:

To do this, monkeytype from Instagram might be a good initial step... But I think we might need a major refactor to get rid of circular imports.

What's everybody's opinion about this?

Thanks

[murrayrm]

It seems like a lot of work and some of the constructor functions (like ss) could be hard to type since they have lots of possibilities.

Since type hints don't affect run-time, can you say more about when/how they are useful (over a well written docstring, for example)?

[joaoantoniocardoso]

It seems like a lot of work and some of the constructor functions (like ss) could be hard to type since they have lots of possibilities.

Indeed, but if we use monkeytype it's automatically done within a few lines... Just tested it here and it works until hit circular imports. Circular imports is something I really dislike about Python, this lack of compilation makes the work with modules so limiting...

Since type hints don't affect run-time, can you say more about when/how they are useful (over a well-written docstring, for example)?

To be sincere, someone could list dozens of good reasons to embrace type hints, but for me, the only practical reason is to be able to run static checks in my codebase.

[FeldrinH]

It is worth noting that currently quite a few functions (including forced_response from the original example), have inferred argument types that cause type checkers to give errors for correct usage. For example for the parameter X0, most type checkers infer the type float, based on the default value, and then give an error if you try to pass an array instead.

This is really frustrating if you have type checking enabled (I generally always have type checking enabled, because even in a largely untyped codebase it helps catch a lot of typos and simple mistakes).

It would be nice to at least mark such arguments as Any or some other extremely general type if 100% correct type hints require too much work.

[ilayn]

The compromising solution for this we did on SciPy is to use stub files. Typically typing the signatures directly makes them unreadable beyond recognition hence keeping a separate stub for functions is much better for typing benefiting folks.

Also this makes, contributions much easier for them to send PR for one or multiple .pyi files without touching the source.