Add type/typing information/hinting to functions, classes, and methods

[Lx]

• I have searched the issues (including closed ones) and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.
• I am willing to lend a hand to help implement this feature.

Feature Request

To improve the development experience when writing plugins or hacking at Pelican's internals, I'd like to add type declarations to the function signatures, class members, etc.

• Is there enough interest in this being done?
• Is this addition welcomed by the Pelican dev team?
• Are there any concerns about compatibility, noting that Pelican seems to require Python 3.6+ and typing hints were introduced in Python 3.5?
• Any tips on how type hinting might be made available to pelicanconf.py itself?

What this solves

Sometimes, the data types expected by various Pelican internals aren't immediately obvious without inspecting the underlying code (sometimes having to dig beyond the first or second level deep). Typing hints would enable IDEs such as Visual Studio Code to know what data types are acceptable and mark code that doesn't seem correct before running it.

[avaris]

In theory, I'd be in favor of this but I see two problems:

• If we do this, then it needs to be required (i.e. mypy through CI etc) and this could make entry level for contributions higher.
• It would almost certainly create merge conflicts with existing PRs.

[jvoisin]

It can be progressive: mypy can (and will) infer types that aren't specified.

[Lx]

If we do this, then it needs to be required (i.e. mypy through CI etc) and this could make entry level for contributions higher.

My understanding could be incomplete, but I believe Python doesn't care too much about type annotations at runtime, and as such, I'm not sure that the CI chain would need to be altered in any way.

• It would almost certainly create merge conflicts with existing PRs.

Adding type annotations would largely only affect function signatures, and lines where variables/members are defined. I've quickly inspected about 15 of the 23 PRs that are currently open, and none of them alter function signatures. A few of them do alter lines declaring empty collection structures, e.g. foo = {}; these would likely create a small (but easily resolved) merge conflict.

[avaris]

My understanding could be incomplete, but I believe Python doesn't care too much about type annotations at runtime, and as such, I'm not sure that the CI chain would need to be altered in any way.

Yes, python doesn't care about annotations but if we are adding annotations we might as well add another CI check for typing using mypy (or similar) to ensure both the annotations and the code is correct.

Adding type annotations would largely only affect function signatures, and lines where variables/members are defined. I've quickly inspected about 15 of the 23 PRs that are currently open, and none of them alter function signatures. A few of them do alter lines declaring empty collection structures, e.g. foo = {}; these would likely create a small (but easily resolved) merge conflict.

Plus PRs that introduce functions but fair point. It might not be as problematic as I thought initially.

[lioman]

• If we do this, then it needs to be required (i.e. mypy through CI etc) and this could make entry level for contributions higher.

Perhaps this will add some burden for those who enter new functions to pelican, but on the other hand you gain valuable code completions and that will be a huge benefit for new contributors.