I'm -0 on this. Given that from __future__ import annotations was rejected in favour of PEP 649, I'm not particularly keen on using it as a temporary workaround, particularly when we do actually have type annotations in place that work.

Without some specific benefit that we can't get any other way (and I consider "not annotating a problem function" to be a valid "other way") I don't think we should do this. But honestly, I find it difficult to care about type annotations, so I'm not going any further than -0.

I'm -0 on this. Given that from __future__ import annotations was rejected in favour of PEP 649, I'm not particularly keen on using it as a temporary workaround, particularly when we do actually have type annotations in place that work.

During type checking phase there is no difference between from __future__ import annotations and PEP 649.

During runtime, for most usecases, there is a bigger difference between PEP 649 and not having from __future__ import annotations on non-PEP 649 versions of Python. As PEP 649 has no runtime effect unless you're inspecting the annotations, which also from __future__ import annotations has no runtime effect unless you're inspecting (though how you inspect is perhaps different).

Therefore I've moved most by codebase to include from __future__ import annotations as I beleive it will be easier supporting multiple versions of Python that have PEP 649 and non-PEP 649 behavior.

Without some specific benefit that we can't get any other way (and I consider "not annotating a problem function" to be a valid "other way") I don't think we should do this.

I don't 100% follow this, but Pip already has to do a lot of if TYPE_CHECKING: for the reasons I already outlined. In fact in PRs I've recently submitted (both accepted and pending review) I had make choices on what to do about type hints that were non-obvious.

With these rules most choices would have become obvious, if it's an annotation only then put it in a type checking block that's import guarded. I then don't have to worry about if the type was introducted in Python 3.8 or if I should create some fake runtime object (which exists in places in the Pip codebase right now).

I find it difficult to care about type annotations, so I'm not going any further than -0.

This is not a hill I'm going to die on, I just found it useful in my own codebases. I've outlined the exact steps I did to create this PR, it can easily be revisited if my predictions of supporting Python versions across PEP 649 and non-PEP 649 come true, by myself or someone else.

One additional benefit, which this commit highlited: 39a910a

Is it prevents importing objects for runtime uses from a module that was only importing that object for type hint annotations, which seems like a strong code smell to me.

Closing this PR due to expressed non-intesterst from Pip maintainers, and as it affects so many files it will inevetibly code rot and it should not be manually fixed but rather the automated steps I described should be reapplied on clean codebase: #12488 (comment)

As a quick summary if anyone wants to revist this again, the benefits are:

• Standardized and enforced use of if TYPE_CHECKING:
• Simpler workflow for devs dealing with annotations that may not be present on all versions of Python or risk introducing circular imports
• Greater compatability between pre PEP 649 and post PEP 649 Python
• Minor runtime performance benefits

Further cleans ups could also be acheived:

• Drop "fake" runtime annotations currently in a few places in the Pip codebase