Add type hints to project

[superlopuh]

Description

I'm working on an extension that depends on this package, and would love to have type hints. Would a PR adding those be helpful?

Benefits

The usual LSP support catching errors without running the code.

Solution Idea

I'd be happy to open a PR.

[facelessuser]

I'm not against adding type hints. This project can be fairly dynamic at times, so not originally designed with type hints in mind which may make this a good amount of work.

1. I'm only interesting in mypy passing. I care less about other typing frameworks.
2. Concerns extend to make sure input and output of functions make sense mainly.
3. Bugs exposed by type hints should be fixed, but I am less concerned about areas where mypy gets confused, as it may often do in highly dynamic libraries. Obviously, there are cleanups that can make this easier for mypy, but I'm not against just ignoring lines or casting in cases where there are difficult dynamic areas that mypy just isn't good at figuring out. For clarification, what I'm simply saying is that I don't want to overcomplicate code just to get mypy to pass in some areas. If the code is sound and requires absurd, rewriting to pass mypy, I'd prefer an ignore or cast.
4. I generally view occasional casting as okay, but, performance wise, casting still causes overhead even if it is a noop. So in cases where excessive casting would be needed, I often just prefer an ignore.
5. I'm usually critical of overcomplicating things if typing features are pulled in that don't work across all versions of currently supported Python at runtime. For now, I recommend using from __future__ import annotations to treat much of the typing for variables and returns as strings during runtime. I'd also be selective as to what typing features are pulled in so we are not required to do complex abstraction to get the features working across multiple versions of Python.
6. Typing should only be applied to the pymdownx folder.
7. Typing setup should all be contained within project.toml.
8. I normally enable it for all Python tests like so: https://github.com/facelessuser/wcmatch/blob/main/pyproject.toml#L125. This catches any issues in supported Python versions.

I imagine such work will be no small task, but I'm happy to have the work done if you are willing. Having type hints in this project is viewed as a nice to have, but low priority in criticality.

[superlopuh]

Sounds reasonable! If a bit of inconsistency is OK with you I would like to add type hints to all the relevant parts of pymdownx.blocks in a PR.

[facelessuser]

I'm not sure what you mean by inconsistency.

[superlopuh]

Like partial type annotations, so only adding them to a couple of files to start with.

[facelessuser]

As long as it's done thoughtfully, partial is fine.

[facelessuser]

Reopening as this the project is not fully type hinted