Should we add the `__all__` attribute to `__future__.pyi`?

[MapleCCC]

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?

[srittau]

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.

[MapleCCC]

@srittau Thanks for the patient reply. The information presented is really helpful and help to clarify things a lot.