[Python-Dev] Concurrent.futures: no type discovery for PyCharm (original) (raw)

Inada Naoki songofacandy at gmail.com
Mon Apr 22 18:55:16 EDT 2019

On Tue, Apr 23, 2019 at 4:40 AM Brett Cannon <brett at python.org> wrote:

On Sat, Apr 20, 2019 at 2:10 PM Inada Naoki <songofacandy at gmail.com> 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 it is just a workaround for PyCharm at the moment.

dir and all has ProcessPoolExecutor and ThreadPoolExecutor for interactive shell. So Python REPL can complete them. But we didn't discussed about "static hinting" version of all in PEP 562.

If we decide it's a "right way", we can update example code in PEP 562.

But when we use lazy import, we want to make import faster. Adding more 3~5ms import time seems not so happy solution.

Maybe, can we add TYPE_CHECKING=False in builtins?

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 to be your biggest bottleneck.

Importing futures module doesn't mean the app really need thread or processes. That's why we defer importing ThreadPoolExecutor and ProcessPoolExecutor.

And people who want apps like vim starts quickly (~200ms), we want avoid every "significant overhead" as possible. Not only "the biggest bottleneck" is the problem.

-- Inada Naoki <songofacandy at gmail.com>

More information about the Python-Dev mailing list