Skip to content
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

Type-hinting #114

Open
billbrod opened this issue Feb 26, 2024 · 0 comments
Open

Type-hinting #114

billbrod opened this issue Feb 26, 2024 · 0 comments

Comments

@billbrod
Copy link
Member

I think this is especially relevant for the jax-casting that happens in #111 , but is a general issue. The question is, how can we effectively use type-hinting for both the static analysis tools and the user. The info we want to communicate is basically: we accept jax arrays, numpy arrays, and pynapple objects. We always return jax arrays or, for those functions decorated with the decorator introduced in #111, pynapple objects (if the input was pynapple)

Posted about this on both the Simons Foundation and US-RSE slacks and got the following advice:

  • @overload (docs, PEP) might be useful for this ,but I don't think the info is well-communicated to user.
  • should read jax's typing docs for their best practices
    • For the jax/numpy array input leads to jax array output, the following is probably what we want:
      def myfunc(arr: jax.typing.ArrayLike) -> jax.Array: 
  • there is a jaxtyping package that allows for annotating array shape and data type.
  • someone recommended that using custom classes can capture the "the output will look like the input":
    SpecialType = Union[pynapple.Tsd, jax.numpy.ndarray]
    def myfunc(input: SpecialType) -> SpecialType:
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant