feat: PotentialFrame is parametric

[nstarman]

This PR makes PotentialFrame parametric wrt to the potential type.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 80.00000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 80.09%. Comparing base (2f7359e) to head (c0b126a). Report is 63 commits behind head on main.

Files with missing lines	Patch %	Lines
src/galax/_interop/galax_interop_gala/potential.py	0.00%	3 Missing :warning:

:exclamation: There is a different number of reports uploaded between BASE (2f7359e) and HEAD (c0b126a). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (2f7359e)	HEAD (c0b126a)
	7	6

Additional details and impacted files

@@             Coverage Diff             @@
##             main     #377       +/-   ##
===========================================
- Coverage   96.59%   80.09%   -16.50%     
===========================================
  Files          76       76               
  Lines        3028     3035        +7     
===========================================
- Hits         2925     2431      -494     
- Misses        103      604      +501     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[nstarman]

@wesselb I'm encountering an interesting Plum issue here. I would expect Plum to be able to grok this return type. Any insight would be greatly appreciated :) Is the problem with Generics?

[wesselb]

Hey @nstarman! I think the problem is indeed with generics. If I'm not mistaken, this reproduces the issue:

In [8]: from typing import Generic, TypeVar

In [9]: T = TypeVar("T")

In [10]: class A(Generic[T]):
    ...:     pass
    ...:

In [11]: resolve_type_hint(A)
Out[11]: __main__.A

In [12]: resolve_type_hint(A[int])
<ipython-input-12-9cf80670f4aa>:1: UserWarning: Could not resolve the type hint of `__main__.A[int]`. I have ended the resolution here to not make your code break, but some types might not be working correctly. Please open an issue at https://github.com/wesselb/plum.
  resolve_type_hint(A[int])
Out[12]: __main__.A[int]

It should fortunately be fairly easy to fix this. This if-statement should be extended to detect generics and recurse into the type parameters of the generic. This SO answer suggests that checking for the attribute __origin__, and the attribute __args__ can be used to get the parameters.

I don't quite have the time to fix this now (sorry :( ), but could possibly at the end of this week or the beginning of next week!

EDIT: I should add that Plum doesn't support typing.Generic at all, mostly because you cannot construct instances of generics, i.e. type(A[int]()) is A.

[nstarman]

Thanks @wesselb for investigating the issue! Before I start addressing this, re your comment edit do you envision plum supporting Generics? Also, does https://github.com/beartype/beartype/releases/tag/v0.19.0 help (e.g. the Use Case 3: Multiple Dispatch). Should I open a PR for This if-statement ?

[wesselb]

Before I start addressing this, re your comment edit do you envision plum supporting Generics?

Ah, I replied without thinking this through too carefully. Plum currently does not support generics, but it could certainly support them in the future. The fact that you cannot construct instances is unimportant! There are two ways to support generics: (1) if beartype at some point supports them, Plum will support them too; and (2) we could implement support for generics without support by beartype.

I think an incomplete implementation supporting commonly used patterns of generics should actually be feasible, although technical.

Should I open a PR for This if-statement ?

If you could, then that would be amazing. :) This should solve the warning.