TL;DR
As I understand, PR #507 precludes the addition of pyelftools stubs to typeshed.
Problem
The purpose of the py.typed marker is to inform static type checkers that a package containing said file includes type information (in the package), either inline (as part of the .py source) or as stubs (separate .pyi files).
elftools currently does neither of those.
The problem is that adding py.typed to a package that does not provide type information breaks the final step of PEP 561 Type Checker Module Resolution Order (MRO):
-
Packages with a py.typed marker file - if there is nothing overriding the installed package, and it opts into type checking, the types bundled with the package SHOULD be used (be they in .pyi type stub files or inline in .py files).
-
Typeshed (if used) - Provides the stdlib types and several third party libraries.
So the net result (and point of this comment) is: By adding py.typed to this library, mypy will never consult Typeshed -- where I was starting to add stubs: python/typeshed#11262
Forward
As I see it, there are two paths forward. In order of preference (mine, and the Python typing community in general):
-
Keep py.typed, and commit to allowing type information to be added in this repository (preferably inline in the .py source, or secondarily as separate .pyi stubs)
- Pros: Type information is in the same repo as the implementation, and always in-sync (version-wise).
- Cons: None really, unless one truly dislikes Python typing
-
Remove py.typed, enabling stubs to be published on Typeshed.
References
cc @fzakaria
TL;DR
As I understand, PR #507 precludes the addition of
pyelftoolsstubs to typeshed.Problem
The purpose of the
py.typedmarker is to inform static type checkers that a package containing said file includes type information (in the package), either inline (as part of the.pysource) or as stubs (separate.pyifiles).elftoolscurrently does neither of those.The problem is that adding
py.typedto a package that does not provide type information breaks the final step of PEP 561 Type Checker Module Resolution Order (MRO):So the net result (and point of this comment) is: By adding
py.typedto this library,mypywill never consult Typeshed -- where I was starting to add stubs: python/typeshed#11262Forward
As I see it, there are two paths forward. In order of preference (mine, and the Python typing community in general):
Keep
py.typed, and commit to allowing type information to be added in this repository (preferably inline in the.pysource, or secondarily as separate.pyistubs)Remove
py.typed, enabling stubs to be published on Typeshed.References
cc @fzakaria