Add useful type hints for possibly a better experience for API users

[sinaatalay]

Hi, this PR is like a question from me. The only change in it is adding a return type to the __getitem__ method of the desc.equilibrium.EquilibriaFamily class.

I started learning DESC, and I thought type hints may make the API a little easier to use.

For example, I wanted to get an equilibrium from the instance of a EquilibriaFamily class by using the indexing operator like below:

equilibria_family = desc.continuation.solve_continuation_automatic(equilibrium)
an_equilibrium = family_of_equilibria[-1]

But, since the __getitem__ method of the EquilibriaFamily class doesn't have a return type, my IDE doesn't know that the variable an_equilibrium is an instance of Equilibrium. So, I have to tell it myself to see the available methods of the Equilibrium class, such as the save method.

Would you be interested if I added useful types like this as I come across them to improve the API experience?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.51%. Comparing base (66e43f2) to head (8885712).
Report is 11 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1344   +/-   ##
=======================================
  Coverage   95.51%   95.51%           
=======================================
  Files          96       96           
  Lines       24044    24044           
=======================================
+ Hits        22965    22966    +1     
+ Misses       1079     1078    -1     

Files with missing lines	Coverage Δ
desc/equilibrium/equilibrium.py	96.07% <100.00%> (ø)

... and 1 file with indirect coverage changes

[YigitElma]

Benchmarks fail due to this PR coming from a fork, I recommend you to use the original repo since you can 😄 . But #1345 should solve the issue for other contributors.

[dpanici]

I think the issue here is that we would need a lot of local imports to do this across all our fxns, and some of those may lead to circular import errors because we have a lot of interdependencies in our files

[sinaatalay]

I think the issue here is that we would need a lot of local imports to do this across all our fxns, and some of those may lead to circular import errors because we have a lot of interdependencies in our files

Oh, right, yes, circular imports will be very likely then.

If we decide to provide types in the future anyway, I am a volunteer.

I will close the PR in a couple of days to see if maybe someone else has a comment on this.