feat: added type hints

[marksie1988]

Description

This PR Adds Type hints.

Some arguments have been updated to allow better support of type hints, this change will only allow correct values to be specified for these items listed below:

• sort_dir
• sort_keys
• artist_monitor
• commands

Now accepts datetime instead of strings where a date is required.

Related issues

• Support for type hints #105

Motivation and Context

By adding support for type hints the module is easier to use and ensure the correct data is provided / returned.

How has this been tested

Testing still on-going

Types of changes

• Docs change / refactoring.
• Non-breaking change (fix or feature that wouldn't cause existing functionality to change/break).
• Breaking change (fix or feature that would cause existing functionality to change/break).

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes don't generate new warnings.
• I have read the CONTRIBUTING document.

[Archmonger]

Honestly not entirely sure how asserts improve anything here, besides making things a bit visually ugly.

[marksie1988]

Honestly not entirely sure how asserts improve anything here, besides making things a bit visually ugly.

The asserts mean we can have the correct type for all on the returns, without it I would need to just use Any which in my eyes defeats the point of using types.

That said, I do agree that it's ugly and seems unnecessary but seems this is a limitation with typing, there are quite a few posts about it online.

[Archmonger]

Given this unfortunate fact...

In the interests of DRY, we should have a helper function that is basically assert_or_return.

[marksie1988]

Given this unfortunate fact...

In the interests of DRY, we should have a helper function that is basically assert_or_return.

Yea that is what I'm going to work on next.

[sourcery-ai]

Sourcery Code Quality Report

❌  Merging this PR will decrease code quality in the affected files by 0.32%.

Quality metrics	Before	After	Change
Complexity	1.31 ⭐	1.57 ⭐	0.26 👎
Method Length	28.37 ⭐	26.95 ⭐	-1.42 👍
Working memory	6.45 🙂	6.50 🙂	0.05 👎
Quality	85.27% ⭐	84.95% ⭐	-0.32% 👎

Other metrics	Before	After	Change
Lines	3002	3037	35

Changed files	Quality Before	Quality After	Quality Change
pyarr/base.py	92.35% ⭐	92.37% ⭐	0.02% 👍
pyarr/exceptions.py	97.50% ⭐	97.01% ⭐	-0.49% 👎
pyarr/lidarr.py	79.10% ⭐	78.26% ⭐	-0.84% 👎
pyarr/radarr.py	91.20% ⭐	91.63% ⭐	0.43% 👍
pyarr/readarr.py	75.52% ⭐	75.69% ⭐	0.17% 👍
pyarr/request_handler.py	80.30% ⭐	80.19% ⭐	-0.11% 👎
pyarr/sonarr.py	90.47% ⭐	90.82% ⭐	0.35% 👍

Here are some functions in these files that still need a tune-up:

File	Function	Complexity	Length	Working Memory	Quality	Recommendation
pyarr/readarr.py	ReadarrAPI._book_json	6 ⭐	131 😞	15 😞	51.23% 🙂	Try splitting into smaller methods. Extract out complex expressions
pyarr/lidarr.py	LidarrAPI._artist_json	6 ⭐	106 🙂	13 😞	57.05% 🙂	Extract out complex expressions
pyarr/lidarr.py	LidarrAPI._album_json	6 ⭐	106 🙂	13 😞	57.05% 🙂	Extract out complex expressions
pyarr/readarr.py	ReadarrAPI._author_json	6 ⭐	101 🙂	13 😞	57.73% 🙂	Extract out complex expressions
pyarr/sonarr.py	SonarrAPI._series_json	4 ⭐	80 🙂	12 😞	64.24% 🙂	Extract out complex expressions

Legend and Explanation

The emojis denote the absolute quality of the code:

• ⭐ excellent
• 🙂 good
• 😞 poor
• ⛔ very poor

The 👍 and 👎 indicate whether the quality has improved or gotten worse with this pull request.

---

Please see our documentation here for details on how these metrics are calculated.

We are actively working on this report - lots more documentation and extra metrics to come!

Help us improve this quality report!

[Archmonger]

Might not be able to review this week - I'm currently in the process of moving houses. I'll get to it as soon as possible.