Speed up importing typing just for TYPE_CHECKING

[thejcannon]

(Somewhat demonstrative PR, but happy to give it the rest of "the treatment" (e.g. tests, documentation, etc...) if it seems OK)

Made in the context of https://discuss.python.org/t/pep-781-make-type-checking-a-built-in-constant/85728/122

I also think _typing.py likely is a bad name (undoubtedly going to collide with some user's usage of _typing.py) so happy to bikeshed on alternate names.

---

On a fresh Ubuntu VM, I installed uv, then uv install 3.14) :

Interpreter baseline:

hyperfine './bin/python3.14 -c "pass"' --warmup 10
Benchmark 1: ./bin/python3.14 -c "pass"
  Time (mean ± σ):       5.3 ms ±   0.2 ms    [User: 4.8 ms, System: 0.7 ms]
  Range (min … max):     5.2 ms …   7.5 ms    512 runs

Importing typing for TYPE_CHECKING

hyperfine './bin/python3.14 -c "from typing import TYPE_CHECKING"' --warmup 10
Benchmark 1: ./bin/python3.14 -c "from typing import TYPE_CHECKING"
  Time (mean ± σ):      11.4 ms ±   0.4 ms    [User: 10.6 ms, System: 0.8 ms]
  Range (min … max):    11.1 ms …  15.3 ms    245 runs

After this change:

hyperfine './bin/python3.14 -c "from typing import TYPE_CHECKING"' --warmup 10
Benchmark 1: ./bin/python3.14 -c "from typing import TYPE_CHECKING"
  Time (mean ± σ):       5.2 ms ±   0.2 ms    [User: 4.8 ms, System: 0.6 ms]
  Range (min … max):     5.1 ms …   7.4 ms    479 runs

[JelleZijlstra]

This makes importing anything else from typing slower, and it likely breaks from typing import *.

[AA-Turner]

It also means the __module__ attribute for all typing objects will be wrong. This PR is a clever trick, but I don't think it solves the problems in the PEP (PEP-0781). For example, there's nothing preventing a future contributor reverting all of this for ease-of-maintenence, so I'd not be confident relying on it as a downstream library/application author who needs to support multiple releases of Python.

A

[thejcannon]

This makes importing anything else from typing slower

By the cost of a string comparison, a lookup for _typing in globals and a getattr call, yeah?

Before:

./bin/python -m timeit 'from typing import Generic'
500000 loops, best of 5: 477 nsec per loop

After:

./bin/python -m timeit 'from typing import Generic'
500000 loops, best of 5: 942 nsec per loop

While the numbers are certainly measurably different:

• It's hard for me to imagine this is occurring in some critical section
• It's also hard for me to imagine this is as performant as possible, given the extremely smart folks around here. I'm sure other folks can chime in with some interesting ideas (can the module's __dict__ be patched/hotswapped? Could this just written in C?)

---

and it likely breaks from typing import *.

Which would likely be fixed by defining __all__ (which I hadn't since I was veeeeeeery lazy (ironic, considering...)), yeah?

[AA-Turner]

Can you test with -Ximporttime? The last line will show the time taken to import typing in microseconds (the module itself and then the cumulative time including imported modules). I think timeit doesn't work for import time measurements as it always uses the cache.

This is a (rough) script I use to benchmark import time measurements:

import subprocess, sys
import statistics

BASE_CMD = (sys.executable, '-Ximporttime', '-S', '-c',)

def run_importtime(mod: str) -> str:
    return subprocess.run(BASE_CMD + (f'import {mod}',), check=True, capture_output=True, encoding='utf-8').stderr


for mod in sys.argv[1:]:
    for _ in range(5):  # warmup
        lines = run_importtime(mod)
    print(lines.partition('\n')[0])
    own_times = []
    cum_times = []
    for _ in range(50):
        lines = run_importtime(mod)
        final_line = lines.rstrip().rpartition('\n')[-1]
        # print(final_line)
        # import time:       {own} |       {cum} | {mod}
        own, cum = map(int, final_line.split()[2:5:2])
        own_times.append(own)
        cum_times.append(cum)
    own_times.sort()
    cum_times.sort()
    own_times[:] = own_times[10:-10]
    cum_times[:] = cum_times[10:-10]
    for label, times in [('own', own_times), ('cumulative', cum_times)]:
        print()
        print(f'import {mod}: {label} time')
        print(f'mean: {statistics.mean(times):.3f} µs')
        print(f'median: {statistics.median(times):.3f} µs')
        print(f'stdev: {statistics.stdev(times):.3f}')
        print('min:', min(times))
        print('max:', max(times))

[thejcannon]

I think timeit doesn't work for import time measurements as it always uses the cache.

(For my own edification, sorry for the noise) "the cache" here is a combo of sys.modules and the module object's __dict__ yeah?

If so, IIUC I think the numbers are precisely showing us that this change as it stands has a small-but-measurable penalty precisely because we don't use the (latter) cache.

I'd venture to guess 477 nsec per loop is the timing of the cache lookups (essentially the timing of sys.modules["typing"].__dict__["Generic"]) and 942 nsec per loop is the timing of code akin to (mod :=sys.modules["typing"]).__dict__.get("Generic") or mod.__getattr__("Generic")

[thejcannon]

Changing the code to:

import sys

__mod__ = sys.modules[__name__]

def __getattr__(name):
    if name == "TYPE_CHECKING":
        return False
    import _typing

    attr = getattr(_typing, name)
    __mod__.__dict__[name] = attr
    return attr

brings it down to 781 nsec per loop (which is arguably a bit surprising! but ultimately I'm sure is explainable and unavoidable)