Setup a minimal mypy config

[alanhdu]

This is a first step to #625: we setups a new CI step with mypy and do the minimal amount of work to get it passing.

Note that by default mypy does not type-check any function that doesn't already have type annotations in the function signature, so for now this isn't really type-checking any function internals. Still, I think having the CI setup will be a good first step.

[ianthomas23]

Thanks for starting this @alanhdu.

If you set up pre-commit hooks locally you can automatically fix the linting errors which are all about import order.

In the end we'd probably run mypy within pre-commit but it seems fine initially to run it in a separate CI run as you have done so that the environment can be carefully controlled.

I have some knowledge of mypy but I am not an expert in it. I probably know enough to be dangerous but not enough to be useful! So please bear with me if I ask some trivial questions.

It seems to me that as we are starting the type annotations from scratch it is a good time to agree a sensible approach for how we should proceed. I am seeing annotations like

var: Union[str, Dict]

but I am more comfortable looking at annotations like

var: str | dict

In other words using | instead of Union and the non-capitalised types for built-in types that do not need to be explicitly imported rather than the capitalised types that do. Is there a particular reason for opting for the former rather than the latter?

[alanhdu]

In other words using | instead of Union and the non-capitalised types for built-in types that do not need to be explicitly imported rather than the capitalised types that do. Is there a particular reason for opting for the former rather than the latter?

It's a good question! I think the answer is probably not.

The issue with the str | dict syntax is that it was only introduced in Python 3.10. For Python 3.8 and 3.9, you have to use add a from __future__ import annotations statement everywhere, but that doesn't always play nicely with run-time uses of type annotations (things like pydantic or attrs). I haven't followed the full saga (https://docs.python.org/3/library/__future__.html#id1 is probably the right breadcrumb to follow), but I got used to avoiding the __future__ import at work since we do a lot based on the runtime type hints.

But since fsspec doesn't do anything with the type hints at runtime, so AFAIK there's no reason not to use the __future__ import.

[alanhdu]

Ok --- pushed two commits: first commit should fix the isort problems, and the 2nd commit shows that things look like if we use from __future__ import annotations.

[martindurant]

and the non-capitalised types for built-in types

I think it was even earlier python versions (3.6? 3.7?) that required this, especially for the case where you wanted to specialise a type like dict.

[hansharhoff]

It was 3.10:

https://peps.python.org/pep-0604/

[alanhdu]

Rebased onto master.