[Python-Dev] Concurrent.futures: no type discovery for PyCharm
njs at pobox.com
Tue Apr 23 12:54:20 EDT 2019
On Tue, Apr 23, 2019, 05:09 Andrew Svetlov <andrew.svetlov at 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev