osdir.com


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

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


Ok thanks for explaining. I will proceed by trying it with typeshed.

Best Regards,
--
Ilya Kamenshchikov


On Tue, Apr 23, 2019 at 9:44 PM Ivan Levkivskyi <levkivskyi at gmail.com>
wrote:

> 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 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:
>>
>> 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 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 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:
>>>>     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/>
>>>
>> _______________________________________________
>> 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/levkivskyi%40gmail.com
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190423/157fe126/attachment-0001.html>