Stricter type hint linting

[l0b0]

Would you be interested in stricter type hint linting? I've implemented these additional mypy settings in another project already:

• check_untyped_defs "Type-checks the interior of functions without type annotations."
• disallow_any_generics "Disallows usage of generic types that do not specify explicit type parameters."
• no_implicit_optional "Changes the treatment of arguments with a default value of None by not implicitly making their type Optional." Basically, declaring a parameter foo: str = None becomes an error, rather than being implicitly treated as Optional[str].
• show_error_codes "Shows error codes in error messages." This makes it easier to write type: ignore[SPECIFIER] comments (which are more specific than the big hammer, type: ignore), since the SPECIFIER part of that is part of the error message.
• warn_redundant_casts "Warns about casting an expression to its inferred type."
• warn_return_any "Shows a warning when returning a value with type Any from a function declared with a non-Any return type."
• warn_unused_ignores "Warns about unneeded # type: ignore comments."

I've also avoided ignore_missing_imports simply by marking only a handful of specific imports as ignored.

[lossyrob]

@l0b0 in #309 I actually moved to Pyright as the type checker, as mypy was having trouble inferring types and allowing some of the techniques I deployed there. I'd be interested if mypy could work with the current typing approach with stricter configuration options without significant changes to the approach. I forget exactly what mypy was erroring on, but if you run default mypy against #309 you'll see some errors that I believe would take some deeper changes to how we're structuring types, or creating a lot more lines of code, where Pyright is able to type check successfully.

[l0b0]

There are 46 errors in the pystac directory, so I'm afraid you'd have to be more specific.

[lossyrob]

That's the issue - mypy reports 46 errors where pyright declares it type correct, and I tend to agree with pyright.

[l0b0]

I've addressed the mypy errors in the PR above. I'd appreciate your input @lossyrob.

[duckontheweb]

Closed via #337

[l0b0]

Closed via #337

Should this actually be closed though @duckontheweb? I haven't got around to introducing the stricter checks mentioned in the original post.

[l0b0]

As a last step in this process I'm working towards strict = True to replace all the current settings. It's slightly stricter than the current settings, and means that the project will be following what the mypy project considers "strict" in the future, which is probably worth it.