Repository navigation
Should we add the __all__ attribute to __future__.pyi? #5569
Description
I have been writing something and it involves accessing the __all__ attribute of the __future__ module. Pylance, the type checker program I am using, complained that __all__ is not a known member of the __future__ module. I reported the issue to the Pylance project, and the developer replied that Pylance followed the typeshed repository for type information in stdlib modules. It seems that the missing of the __all__ attribute in the __future__.pyi stub is the root cause.
I must admit that I am not sure what should be included into type stub and what should not. Especially after seeing two pull requests (#3357 and #2161) removing __all__ from stubs, I am not sure whether we should add the __all__ attribute to __future__.pyi or not?
Activity
srittau commentedon Jun 3, 2021
We don't really have a policy surrounding this, and it's handled inconsistently in typeshed. But in the preparation of a type stub PEP (whose future is unknown), we came to the conclusion that
__all__in stubs should match__all__in the implementation: https://github.com/srittau/type-stub-pep/blob/type-stub-pep/pep-9999.rst#__all__I'd accept a PR that copies
__all__to__future__.pyi.Add `__all__` to `__future__.pyi` (#5570)
MapleCCC commentedon Jun 4, 2021
@srittau Thanks for the patient reply. The information presented is really helpful and help to clarify things a lot.