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

[Inada Naoki]

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>