Glenn Linderman v+python at g.nevcal.com
Sat Apr 20 18:26:14 EDT 2019

• Previous message (by thread): [Python-Dev] Concurrent.futures: no type discovery for PyCharm
• Next message (by thread): [Python-Dev] Concurrent.futures: no type discovery for PyCharm
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

---

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>

---

• Previous message (by thread): [Python-Dev] Concurrent.futures: no type discovery for PyCharm
• Next message (by thread): [Python-Dev] Concurrent.futures: no type discovery for PyCharm
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

---

More information about the Python-Dev mailing list