Add py.typed for marking the library as type checkable

[heckad]

#569

[martasd]

Hi. Can this PR not be merged?

[lahirumaramba]

Hi. Can this PR not be merged?

Thanks for surfacing this. I don't think we have added type hints for all the functions, yet. However, since this PR was created we have added type hints to all the new functions. This should be a reasonable change to merge. I will take a look

[andersonaddo]

Heya, just bumping this so it doesn't get lost (I figure you're busy).
Would be nice to know if this is blocked by some internal discussions or if you just have a lot on your plate.

[jonathanedey]

LGTM, thank you @heckad for the contribution!

[ViktorSky]

This is bad practice, py.typed should only exist when the package has a type distribution, either a stub file or inline annotations.

[heckad]

This is bad practice, py.typed should only exist when the package has a type distribution, either a stub file or inline annotations.

Why? If you add them, mypy will check the typing. Even if there are at least some typings, it’s better than nothing. Now, even existing types won't be checked.

[ViktorSky]

This is bad practice, py.typed should only exist when the package has a type distribution, either a stub file or inline annotations.

Why? If you add them, mypy will check the typing. Even if there are at least some typings, it’s better than nothing. Now, even existing types won't be checked.

The py.typed file (as defined in PEP 561) serves as an explicit declaration that a package distributes valid type information (via inline annotations or stub files)

Type checkers like mypy, pyright, or pylance interpret py.typed as a promise that the package adheres to PEP 561. If no types exist, users may incorrectly assume the package is "type-safe", while in reality, all imports still resolve to Any.

You can see more details on this topic in the typing specification

Here is an example of a correct implementation of py.typed https://github.com/encode/httpx