You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RadarrAPI.get_movie() has quite odd functionality. This isn't pyarr's fault, the v3 Radarr API simply gives you a lot of options for getting a movie in your library, and it makes sense to encapsulate them into one function.
If you request using a TMDB ID, the API responds with a singleton list if it finds the movie, else it responds with an empty list. Meanwhile, if you request using a Radarr database ID, the API responds with the JSON of the movie, or it returns the resource not found status code.
It was discussed in #105 how the type hints should be constructed, however narrowing the types through the assert_return function appears to not be working very well for me when Unions are involved. Pylance and mypy for that matter get quite upset about me trying to call __getitem__ on lists ("error: No overload variant of "getitem" of "list" matches argument type "str"") and indexing Unions with ints ("error: Invalid index type "int" for "Union[List[Dict[str, Any]], Dict[str, Any]]"").
Also, #113 was meant to fix #111, however the SonarrAPI.get_series() part was missed.
Expected behaviour
I was generally unaware of how to tackle the problem the proper way as types in Python are relatively new to me, however I stumbled across this article explaining, what appears to be after further research, the standard (typing.overload decorated function signatures).
For instance, RadarrAPI.get_movie() would have the following signatures (side note: should tmdb be keyword-only?):
Yes I have started adding tests, initially with Sonarr which has picked up some issues with the type hints, as I write the tests I am resolving the issues. However its taking me time to write them due to there being so many functions.
I plan to work on the Radarr tests second as I think people mainly use Sonarr & Radarr.
That's what I have been looking at, however as he is using objects for the responses the tests are far more substantial.
Really all we need to test for is that the expected type is returned e.g. dict / list on the JSON, the correct errors are raised which I'm covering in the current PR.
Unless there are any obvious tests that I'm missing? I'm new to setting up tests so I may well be missing something obvious.
I almost have all of the Sonar API setup with tests.
Is there an existing issue for this?
Current Behaviour
RadarrAPI.get_movie()
has quite odd functionality. This isn't pyarr's fault, the v3 Radarr API simply gives you a lot of options for getting a movie in your library, and it makes sense to encapsulate them into one function.If you request using a TMDB ID, the API responds with a singleton list if it finds the movie, else it responds with an empty list. Meanwhile, if you request using a Radarr database ID, the API responds with the JSON of the movie, or it returns the resource not found status code.
It was discussed in #105 how the type hints should be constructed, however narrowing the types through the
assert_return
function appears to not be working very well for me whenUnion
s are involved. Pylance and mypy for that matter get quite upset about me trying to call__getitem__
onlist
s ("error: No overload variant of "getitem" of "list" matches argument type "str"") and indexingUnion
s withint
s ("error: Invalid index type "int" for "Union[List[Dict[str, Any]], Dict[str, Any]]"").Also, #113 was meant to fix #111, however the
SonarrAPI.get_series()
part was missed.Expected behaviour
I was generally unaware of how to tackle the problem the proper way as types in Python are relatively new to me, however I stumbled across this article explaining, what appears to be after further research, the standard (
typing.overload
decorated function signatures).For instance,
RadarrAPI.get_movie()
would have the following signatures (side note: shouldtmdb
be keyword-only?):This could be put right in the source files, or in stub files. With how many signatures needed though, I think stub files would make the most sense.
I can try my hand at a PR for this, however my non-Radarr API knowledge is pretty lacking.
Steps To Reproduce
No response
Pyarr Version
4.1.0
Python Version
3.10.0
Example Code
No response
Relevant log output
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: