Re: [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 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.

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

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

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

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

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

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:

Re: [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 wrote: > On

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

On Tue, Apr 23, 2019, 05:09 Andrew Svetlov 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

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

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

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

On Tue, Apr 23, 2019 at 4:40 AM Brett Cannon wrote: > > On Sat, Apr 20, 2019 at 2:10 PM Inada Naoki wrote: >> >> "import typing" is slow too. > > But is it so slow as to not do the right thing here and use the 'typing' > module as expected? I don't know it is not a "right thing" yet. It feel

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

On 22Apr2019 1521, Andrew Svetlov wrote: I see the chicken and egg problem here. If we are talking about typing module usage -- typeshed is the type hints provider. If PyCharm doesn't want to use it -- it is not CPython problem. I think there is no need to change python code itself but used

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

I see the chicken and egg problem here. If we are talking about typing module usage -- typeshed is the type hints provider. If PyCharm doesn't want to use it -- it is not CPython problem. I think there is no need to change python code itself but used tooling. On Mon, Apr 22, 2019 at 11:06 PM

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

On Sat, Apr 20, 2019 at 2:10 PM Inada Naoki wrote: > "import typing" is slow too. > But is it so slow as to not do the right thing here and use the 'typing' module as expected? If you have so much work you need to launch some threads or processes to deal with it then a single import isn't going

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

On Sat, Apr 20, 2019 at 2:11 PM Inada Naoki wrote: > > "import typing" is slow too. Many static analysis tools will also accept: TYPE_CHECKING = False if TYPE_CHECKING: ... At least mypy and pylint both treat all variables named TYPE_CHECKING as true, regardless of where they came from.

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

On 4/20/2019 2:08 PM, Inada Naoki wrote: "import typing" is slow too. 2019年4月21日(日) 1:43 Ilya Kamenshchikov >: alright, so would an import under TYPE_CHECKING guard be an option? like: from typingimport TYPE_CHECKING if TYPE_CHECKING:

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

"import typing" is slow too. 2019年4月21日(日) 1:43 Ilya Kamenshchikov : > alright, so would an import under TYPE_CHECKING guard be an option? like: > > from typing import TYPE_CHECKING > if TYPE_CHECKING: > from .process import ProcessPoolExecutor > from .thread import ThreadPoolExecutor >

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

alright, so would an import under TYPE_CHECKING guard be an option? like: from typing import TYPE_CHECKING if TYPE_CHECKING: from .process import ProcessPoolExecutor from .thread import ThreadPoolExecutor Perhaps we can have both clarity and performance.

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

See https://bugs.python.org/issue32596 ___ 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/archive%40mail-archive.com