Type annotations in dash (+ add mypy tests in CI)

[anders-kiaer]

With Python 2 dropped, we would love to see Dash type hinted. Benefits:

• Wrong usage of the dash package APIs can be captured using mypy when writing Dash apps, even directly in editors.
• Easier to help with community PRs (easier to read code that is type hinted).
• It is a prerequisite to later take a look at a killer feature: Type hint/editor help on props in the TypeScript/ReactProp ↔ mypy/Python hint border: Allow extracting meta data from typescript components #719 (comment).

Type hinted code base will also make it easier for Plotly to onboard new developers to plotly/dash. And it well help you detect type flow issues/bugs in the Python code not already covered (so far I found two type issues).

Happy to take this further if interest. What do you think @alexcjohnson et al.?

[anders-kiaer]

Probably due to python/mypy#1362.

[anders-kiaer]

If taken further, I'll try replace dict with Dict with more information about the underlying structure.

[anders-kiaer]

The list of ignore errors will be shortened if PR is taken further. If it is too much to efficiently (merge conflicts etc) do in one PR, the mypy.ini file could be used to split out mypy / type hint work over several PRs.

[chriddyp]

This is really awesome @anders-kiaer ! I've been in 2.7 backwards compatibility for so long that I don't have much 1st hand experience with Python-typing. Any downsides to doing this?

[anders-kiaer]

This is really awesome @anders-kiaer ! I've been in 2.7 backwards compatibility for so long that I don't have much 1st hand experience with Python-typing. Any downsides to doing this?

Thanks @chriddyp. I would say there are no real downsides (at least not compared to what you get back from type hinting). If I should try to come up with something, it would perhaps be slightly increased startup time of apps, and more code to write.

The first is to a large degree solved in Python 3.7+ (https://docs.python.org/3/whatsnew/3.7.html#pep-563-postponed-evaluation-of-annotations), and I would say that even in 3.6 you don't see this in practice (e.g. import plotly takes a long time typically in Python 3.6, so the CPython/Python std.lib type hint startup time increase discussion isn't something I would consider here - especially since Python 3.6 has EOL this year, including security fixes).

For the latter the extra code to write is in our experience more than justified by the value type hints give (automatic type testing, readability, help editors give the Dash app programmer even better live feedback on autocompletion/code issues etc.). It also reduces the need of writing docstrings/comments (which easily could get out of sync with the code). Sphinx can use type hints/annotations instead of rst-written type hints in docstrings (such that docstrings are only used for text explaining e.g. what the functions do). And for projects that don't use Sphinx and compile documentation themselves (or need type annotations during runtime for some other reason) can extract the type hints with https://docs.python.org/3.6/library/inspect.html#inspect.getfullargspec from std.lib:

annotations is a dictionary mapping parameter names to annotations. The special key "return" is used to report the function return value annotation (if any).

🙂

[tuchandra]

Hi @anders-kiaer - are you still actively working on this? I'd love to contribute if I can. What do you see as the minimal amount necessary to get something landed, assuming that doing it all at once will be challenging?

[anders-kiaer]

Hi @tuchandra 👋

are you still actively working on this?

No, after the upside/"downside" input comment above, I didn't dare spend more time on it before clear indication from maintainers that "this will likely be merged when ready" 🙂 It is quite time consuming to in detail type hint when not knowing the internal code base in detail from before (and by nature a type hint PR touches a lot of code ⇾ easy to get merge conflicts if not quickly reviewed/merged).

What do you see as the minimal amount necessary to get something landed, assuming that doing it all at once will be challenging?

All at once, at least for a single person, would be challenging (and probably extra time consuming in total due to the likely merge conflicts). I guess a minimal amount could be:

• Type hint ≥ 1 modules in dash.
• Make sure mypy is green on dash (i.e. that type hinted modules passes, and other modules are configured to be ignored).
• We add the mypy test to dash's CI workflow.

Future PRs would then type hint ≥ 1 new modules and correspondingly shorten the mypy ignore list.

I'd love to contribute if I can.

Please feel free to copy my commit as starting point. 🙂 (I can probably also grant you write access to my fork/branch and we do it as a joint effort splitting some modules between us. Let me know if prefer this instead.)

[tuchandra]

Got it, sure. Looking over this PR, it looks like you were focusing on the core dash module; I'm thinking starting with the public API might be easier, though? It could possibly be added to typeshed instead, if the maintainers here are not able to spend time on this.

[tuchandra]

@chriddyp, would adding the type stubs to typeshed be something you (or the other maintainers) are supportive of?

[gothicVI]

Is this still considered? I'm highly in favor of adding type hints as dash is currently the only dependency we have that breaks full mypy coverage but at the same time is often the sole source of type errors.

[gvwilson]

thank you again for this @anders-kiaer - our next major release is going to include some work by @T4rk1n that addresses a lot of these issues.