Create py.typed
# What does this PR do?

This creates a [py.typed as per PEP 561](https://www.python.org/dev/peps/pep-0561/#packaging-type-information) that should be distributed to mark that the package includes (inline) type annotations.

Thanks, @willfrey! I'm reading the PEP 561 as I was unaware of this file, but I'm not sure I'm getting everything. Is this file necessary for downstream type checkers (such as `mypy`) to understand the types from `transformers`?

If that is so, is there no need for any additions, such as a mention in our setup.py's `package_data`? And is the addition of that single file enough to make the package compatible with downstream type checkers, or should we vigorously check that all types are currently defined, and enforce all types from now on for the package?

Thank you!<|||||>`py.typed` needs to be distributed with the top-level `transformers` package as per [PEP 561](https://www.python.org/dev/peps/pep-0561/#packaging-type-information).

This should be all that you need to tell downstream type checkers that the code in the package is typed. It'll make mypy behave a lot more nicely, that's for sure. Some type checkers, like Pyright will infer types from library code directly, which is why mypy freaks out but Pylance tries to do the right thing. My experience with Pylance though is that it is very slow trying to infer types based on all the non-standard behavior being done to hack the various namespaces in the package.

I _think_ partial types are okay here, they'll just be inferred implicitly as `Any`. I wouldn't defensively enforce types because that defeats the whole point of structural sub-typing (duck-typing) that makes Python so great. Type annotations are meant (among other things) to allow you to identify logical errors in your code that a compiler would normally catch.

Another reason to not enforce it is that people tend to over-specify the types for method parameters, which can get annoying. For example, you might annotate something as `List[str]` (or `list[str]` for Python 3.9 and later) but you really only needed `collections.abc.MutableSequence[str]`, `collections.abc.Sequence[str]`, or perhaps just `collections.abc.Iterable[str]`.<|||||>Thank you for the explanation, that all makes a lot of sense. I tried your PR with `mypy` to see if it would be able to analyze the types, yet I'm still getting the error that should be resolved: 
```
error: Skipping analyzing "transformers": found module but no type hints or library stubs
```
I suspect this has to do with `package_data` being ill-defined as I see it defined in a few sources, but I'm unsuccessful at completing it and resolving this error. 

I'm trying to understand what issue would adding `py.typed` resolve, to make sure we're not forgetting anything/couldn't improve it by understanding the use-cases this would enable.<|||||>I'm assuming mypy is trying to analyze transformers in a virtual environment where it's been pip installed? If so, check in the virtualenv to see if the py.typed file is in the transformers directory.

I just updated setup.py to include py.typed as package data.<|||||>A similar PR (https://github.com/huggingface/datasets/pull/2417) was recently merged in the datasets library as well.

@willfrey 
A small nit. It's advised by MyPy to set the `zip_safe` argument of `setuptools.setup` to `False`.

@LysandreJik 
[This thread on SO](https://stackoverflow.com/questions/60856237/mypy-cant-find-type-hints-for-black) explains what happens when running MyPy on code that imports a 3rd party lib that's not PEP561-compliant.
<|||||>@willfrey Do you mind setting the `zip_sage` argument as mentioned by @mariosasko?
We'll merge the PR afterward. Thank you!<|||||>@LysandreJik Done!