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

[Andrew Svetlov]

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 TYPE_CHECKING:
    import ...

requires mypy modification.

if False:
    import ...

Works right now for stdlib (mypy ignores stdlib code but uses typeshed
anyway) but looks a little cryptic.
Requires a comprehensive comment at least.

On Tue, Apr 23, 2019 at 1:59 AM Inada Naoki <songofacandy at gmail.com> wrote:
>
> 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>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com



-- 
Thanks,
Andrew Svetlov