Mypy doesn't use source code of stlib for analysis and instead uses stub files from typeshed. IIUC PyCharm can also do that (i.e. use the typeshed stubs).
The whole idea of typeshed is to avoid changing stlib solely for the sake of static analysis. Please open an issue on typeshed an/or PyCharm tracker.

--
Ivan



On Tue, 23 Apr 2019 at 20:38, Ilya Kamenshchikov <ikamenshchikov@gmail.com> wrote:
How would we answer the same question if it was not a part of stdlib?
I am not sure it is fair to expect of Pycharm to parse / execute the __getattr__ on modules, as more elaborate implementation could even contain different types per some condition at the runtime or anything at all.
The code:
TYPE_CHECKING = False
if TYPE_CHECKING:
    from .process import ProcessPoolExecutor
    from .thread import ThreadPoolExecutor
works for type checking in PyCharm and is fast. 
This is how stdlib can be an example to how side libraries can be implemented. If we can agree that this is the only clear, performant and sufficient code - then perhaps modifying mypy is a reasonable price to pay.
Perhaps this particular case can be just patched locally by PyCharm /JetBrains, but what is a general solution to this class of problems?

Best Regards,
--
Ilya Kamenshchikov


On Tue, Apr 23, 2019 at 7:05 PM Guido van Rossum <guido@python.org> wrote:
In any case I think this should be filed (by the OP) as an issue against JetBrains' PyCharm issue tracker. Who knows they may be able to special-case this in a jiffy. I don't think we should add any clever hacks to the stdlib for this.

On Tue, Apr 23, 2019 at 9:59 AM Nathaniel Smith <njs@pobox.com> wrote:
On Tue, Apr 23, 2019, 05:09 Andrew Svetlov <andrew.svetlov@gmail.com> wrote:
I agree that `from typing import TYPE_CHECKING` is not desirable from
the import time reduction perspective.

>From my understanding code completion *can* be based on type hinting
to avoid actual code execution.
That's why I've mentioned that typeshed already has the correct type
information.

if TYPE_CHECKING:
    import ...

requires mypy modification.

if False:
    import ...

Works right now for stdlib (mypy ignores stdlib code but uses typeshed
anyway) but looks a little cryptic.
Requires a comprehensive comment at least.

Last time I looked at this, I'm pretty sure `if False` broke at least one popular static analysis tool (ie it was clever enough to ignore everything inside `if False`) – I think either pylint or jedi?

I'd suggest checking any clever hacks against at least: mypy, pylint/astroid, jedi, pyflakes, and pycharm. They all have their own static analysis engines, and each one has its own idiosyncratic quirks.

We've struggled with this a *lot* in trio, and eventually ended up giving up on all forms of dynamic export cleverness; we've even banned the use of __all__ entirely. Static analysis has gotten good enough that users won't accept it not working, but it hasn't gotten good enough to handle anything but the simplest static exports in a reliable way:

The stdlib has more leeway because when tools don't work on the stdlib then they tend to eventually add workarounds. I'm just saying, think twice before diving into clever hacks to workaround static analysis limits, and if you're going to do it then be careful to be thorough. You're basically relying on undocumented bugs, and it gets really messy really quickly.

-n
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org


--
--Guido van Rossum (python.org/~guido)
Pronouns: he/him/his (why is my pronoun here?)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/levkivskyi%40gmail.com