[Python-Dev] Concurrent.futures: no type discovery for PyCharm (original) (raw)

Guido van Rossum guido at python.org
Tue Apr 23 15:43:54 EDT 2019

The general solution is

import typing if typing.TYPE_CHECKING:

The hack of starting with

TYPE_CHECKING = False

happens to work but is not endorsed by PEP 484 so is not guaranteed for the future.

Note that 3rd party code is rarely in such a critical part for script startup that the cost of import typing is too much. But the stdlib often is in the critical path for script startup, and some consider the time spent in that import too much (startup time should be in the order of tens of msec so every msec counts -- but once you start importing 3rd party code you basically can't make it that fast regardless).

Anyway, the stdlib should almost never be used as an example for non-stdlib code -- there are many reasons for this that I don't want to have to repeat here.

On Tue, Apr 23, 2019 at 12:33 PM Ilya Kamenshchikov < ikamenshchikov at 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: > TYPECHECKING = False if TYPECHECKING: 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 at 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 at pobox.com> wrote: >>>> On Tue, Apr 23, 2019, 05:09 Andrew Svetlov <andrew.svetlov at gmail.com> >> wrote: >>>>>> I agree that from typing import TYPECHECKING 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 TYPECHECKING: >>> 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: >> https://github.com/python-trio/trio/pull/316 >> https://github.com/python-trio/trio/issues/542 >>>>> 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 at 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?)* > <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> >>

--Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20190423/f294e5a9/attachment.html>

More information about the Python-Dev mailing list