[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 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.
>>     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?)*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190423/c4035a49/attachment.html>