httpx: Missing py.typed declaration?

mypy is complaining about not being able to find type annotations for httpx:

error: Cannot find module named 'httpx'

I’m somewhat new to using type annotations/static type checking in Python, but from the mypy documentation here it looks like there may be a missing declaration in setup.py?

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 21 (16 by maintainers)

Commits related to this issue

remove include_package_data and MANIFEST.in Fixes #193 — committed to graingert/httpx by graingert 5 years ago
Add PEP-561 py.typed file This commit adds a py.typed file, which marks the package as having type information available. For more information, see https://mypy.readthedocs.io/en/stable/installed_pa... — committed to lalten/openhtf by lalten 3 years ago

Most upvoted comments

Related: It’s a bit of a gross hack that we need a py.typed file to indicate that we’re a well typed package. I don’t really dig it.

Is there anything productive that we could do to push for a nicer alternative to become adopted in whichever of Python/MyPy/PyPI this is relevant too? (Eg. A top-level __typed__ = True variable in packages? A setting in PyPI package info?)

tomchristie on Oct 4, 2019

Right on, thanks all!

@sethmlarson @florimondmanca This library is excellent btw

kylebebak on Sep 25, 2019

Just following up – this looks to be fully resolved as of 0.7.5. Thanks!

andrewmwhite on Oct 10, 2019

Out of curiosity, I compared the usage of py.typed between mypy and pyre (an alternative Python static type checker implemented in OCaml).

It seems Pyre doesn’t use py.typed at all. Instead, users must to specify a --search-path to specify extra paths where typed packages should be used, and that’s how pyre looks for type annotations in external packages. For example:

# Can also be passed via a private config file.
pyre --search-path=venv/lib/python3.7/site-packages/

So instead of requiring package authors mark the package as typing-ready and have the type checker auto-discover those, Pyre switches the responsability on the user to tell Pyre where it should look for type annotations.

Proof of concept: Pyre was able to use typing data from asgi-lifespan==0.4.1, even though Mypy couldn’t because only 0.4.2+ is PEP 561-compliant.

My main theory of why a special marker file was used is to increase performance. Pyre builds are very slow (30s-ish for a single-module project only with asgi-lifespan as a main dependency), and how little it has to build depends on how specific the user’s --search-path is. On the other hand, mypy “just works”, provided that imported packages comply with PEP 561.

In terms of productivity, we could push for something like __typed__ = True in packages’ __init__.py (it sounds rather cheap to check for as well), but unfortunately that’d mean going through another round of PEP, risking a split in the ecosystem, and making mypy more complex at it’d have to support both APIs indefinitely. The upside would be an arguably simpler package type distrubution setup, but I’m not sure I’d personally want to be involved in this endeavour.

florimondmanca on Oct 7, 2019

Did you properly install the module via pip? I had an issue occurring where I installed a module via pip but my Python wasn’t in my environment variables. Preventing my IDE from locating the installed module.

Hope this helps or makes sense 😃

ChristopherMillones on Aug 6, 2019