GeezerVison

Everytime I see local imports for inspect, I feel that we need to have a lower-level inspect utililty that can have less functions but more common to avoid having to import inspect.

What I can suggest for this specific PR is to use lazy import inspect instead at the top-level to make it a bit cleaner. For backports, we'll however need to use a local import. Note that we have other places with a local import to inspect, which you can eventually remove since we would have both a lazy and a local import (which would be redundant). I'll let @JelleZijlstra decide whether to want lazy imports.

If we switch to lazy imports, we'll also need to update the lazy import tests somewhere to check that inspect is lazily imported.

Maybe inspect.unwrap should live in functools instead, it's closely related to functools.wraps after all. But it's probably too late for that. Lazy importing sounds good to me.

I think we can just use lazy import inspect now and get rid of those lazy load stuff?

There was some controversy about using PEP 810 too widely in the stdlib https://discuss.python.org/t/concerns-about-x-lazy-imports-none/106203

I don't have a strong opinion myself, to be clear

@picnixz Done, replaced both _lazy_load_getattr_static and _lazy_load_unwrap with a _LazyInspect class following the existing _LazyAnnotationLib pattern already in the file.

There was some controversy about using PEP 810 too widely in the stdlib

Jelle said he was fine so I think we can do the switch unless it's breaking something. @raminfp please check that the concerns expressed in the DPO thread are not concerns, but do so without using an LLM.

Why do we have this construction? Please don't use an LLM to generate this. Just use lazy import inspect and check if there is nothing wrong with that construction as per the DPO thread.

For annotationlib, we'll clean it up either in a follow-up if codeowners do want it, or we will keep it as is until we need to modify annotationlib calls somewhere.