Since PEP 562 is implemented, we can use lazy imports easily.

Asyncio uses concurrent.futures.Future and concurrent.futures.ThreadPoolExecutor,
but not concurrent.futures.ProcessPoolExecutor by default.

Since importing concurrent.futures.process is slow, I want to import it lazily.
And it make sense to import concurrent.futures.thread too, because it's very
easy when we start to use __getattr__ once.

Here is quick benchmark:


$ ./python -m perf command ./python -c 'import asyncio'  # patched
.....................
command: Mean +- std dev: 60.5 ms +- 0.1 ms
$ git stash
$ ./python -m perf command ./python -c 'import asyncio'  # original
.....................
command: Mean +- std dev: 74.3 ms +- 0.2 ms

New changeset 6690bb9f17d34eb3dec0aca8919d8d27d6c3c452 by INADA Naoki in branch 'master':
bpo-32596: Lazy import concurrent.futures.process and thread (GH-5241)
https://github.com/python/cpython/commit/6690bb9f17d34eb3dec0aca8919d8d27d6c3c452

New changeset 4666ec597c38eea06a22bcfb4157d92a0abf891c by INADA Naoki in branch 'master':
bpo-32596: Make lazy-load portable (GH-5316)
https://github.com/python/cpython/commit/4666ec597c38eea06a22bcfb4157d92a0abf891c

I don't think this was a good idea. Making some imports implicitly lazy introduces unpredictability in stdlib imports. Here is an example bug report:
https://issues.apache.org/jira/browse/ARROW-11983

What are issues with using global variable as import target?

See this comment.
https://github.com/python/cpython/pull/5241#discussion_r162765765

Thank you Inada-san. My first intention when I seen this code was to simplify it, but then I have found that it was an intentional change.

It may be easy to detect such code and raise a syntax warning or error. Or get rid of this limitation and allow globals officially here.