I think making some import lazy definitely makes sense. Making import pdb faster benefits more than pdb itself - pytest is a great example. But how did we choose the libraries to lazy import? Is it quite arbitrary? Is there a rule to follow in stdlib - like which are the libraries we should lazy import? Or did we leave the ones that will "definitely" be used? I'm not against the current list, but it might be clearer for future developers if we have a guidance to follow.

I ran:

pip install tuna
./python.exe -X importtime -c "import pdb" 2> import.log
tuna import.log

This gives the blue diagram to visualise the import times.

Then looked at the slowest imports, and made them lazy one by one.

Some would gett reified right away, like bdb (due to class Pdb(bdb.Bdb, cmd.Cmd)) and code (due to class _PdbInteractiveConsole(code.InteractiveConsole)), so I left those as eager imports but also made some of their own imports lazy in the same way to make then lighter.

Others like typing also get reified immediately (due to @typing.override), so that was also left as eager. We've tackled making typing faster before.

The tests ensure that a lazy import doesn't end up getting immediately reified due to some other change. If that happens down the line, we can either do something to ensure it remains lazy, or make a conscious decision to allow it be eager, and update the test.

We also have some deferred imports, like runpy, which are imported inside functions. This was the pre-lazy way of doing it, so we can now hoist them up as explicit lazy imports.