A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2019-April/157145.html below:

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

[Python-Dev] Concurrent.futures: no type discovery for PyCharm [Python-Dev] Concurrent.futures: no type discovery for PyCharmGlenn Linderman v+python at g.nevcal.com
Sat Apr 20 18:26:14 EDT 2019
On 4/20/2019 2:08 PM, Inada Naoki wrote:
> "import typing" is slow too.
>
> 2019年4月21日(日) 1:43 Ilya Kamenshchikov <ikamenshchikov at gmail.com 
> <mailto:ikamenshchikov at gmail.com>>:
>
>     alright, so would an import under TYPE_CHECKING guard be an
>     option? like:
>
>     from typingimport TYPE_CHECKING
>     if TYPE_CHECKING:
>          from .processimport ProcessPoolExecutor
>          from .threadimport ThreadPoolExecutor
>
>     Perhaps we can have both clarity and performance.
>

How about:


from faketyping import TYPE_CHECKING

where faketyping.py:

TYPE_CHECKING = None


I don't know enough about how TYPE_CHECKING (or typing) is optionally 
enabled to come up with an exactly correct proposal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190420/c8f85035/attachment.html>
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4