[Python-Dev] Concurrent.futures: no type discovery for PyCharm

[Steve Dower]

On 22Apr2019 1521, Andrew Svetlov wrote:
> I see the chicken and egg problem here.
> If we are talking about typing module usage -- typeshed is the type
> hints provider.
> If PyCharm doesn't want to use it -- it is not CPython problem.
> 
> I think there is no need to change python code itself but used tooling.

It's not typeshed related, it's most likely because Python 3.7 
Lib/concurrent/future/__init__.py switched from always importing the 
subclasses to doing it lazily in a module __getattr__ function. I assume 
for performance, since either submodule may have deep import chains.

Presumably PyCharm has not yet added support for this, and so it simply 
doesn't know how to resolve ThreadPoolExecutor or ProcessPoolExecutor 
without actually executing code (which most static analysers will 
hesitate to do, since you don't know if that code is "os.system('rm -rf 
/')" until it's too late).

Perhaps for the sake of IDEs and static analysers we could make a policy 
for standard library modules to include an "if False:" or "TYPE_CHECKING 
= False; if TYPE_CHECKING:" block that includes the import statement 
when adding lazy module attribute resolution?

Cheers,
Steve