Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

I see this goes back to sphinx-doc/sphinx#9813 which is commented as being tricky to solve. The solution here seems just partial, though: if it were so easy, wouldn't sphinx just set TYPE_SETTING = True?

Why were they in if to begin with? Any cons we need to know about unleashing this as mandatory runtime import?

@pllim it was driven by 2 things: a ruff config to prefer to put type-time imports in a type-checking block and the thought that it could prevent increased import times. The former has come under flack for the difficulty it causes runtime type checkers (and sphinx). The latter can be true, but doesn't appear to be noticeable in most (any?) cases thus far.

Thanks, @eerovaher and @nstarman, interesting to see that the whole if TYPE_CHECKING thing is getting a bit of a second thought. Of course, the import loop problem can be seriously annoying, and it is hard to see how to solve that for annotations other than by something like putting it in a if TYPE_CHECKING block...

Stdlib and 3rd party shouldn't be problematic, but yeah 1st party is interesting.
Re. First party annotations, the suggested recourse is

1. Full paths
   Instead of

if TYPE_CHECKING:
    from mylib import y

def func() -> y: ...

Do

if TYPE_CHECKING:
    import mylib

def func() -> mylib.y: ...

2. Stringification (works, never preferred) but even for this opt 1 helps with runtime type checkers.

3. Wait for that new Python PEP for forward refs. But if 1 and 2 work in the interim we should do those. 3 will eventually fix most things.

I already had to fix a merge conflict and the longer this stays open, the more likely that I will have to fix more. To prevent this from getting stuck in review I am setting a deadline for next Thursday (2025.06.12). If this is not merged by that time then I will limit this pull request to the sub-packages with approvals and start opening separate pull requests for the remaining sub-packages, one sub-package per pull request.

@nstarman, did you approve only for cosmology or also for units?

@eerovaher. Both.

Basically all subpackages have the same kind of fixes, so if we decide that runtime import isn't a problem, this is probably good to go. Any outstanding discussions left?

Runtime imports from the standard library should not be controversial and this pull request is not concerned with third party or first party imports.

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

git checkout v7.1.x
git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

git cherry-pick -x -m1 09795abdae6ebf71bc58b04be52faf79e198a1a2

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

git commit -am 'Backport PR #18191: Import standard library types at runtime'

4. Push to a named branch:

git push YOURFORK v7.1.x:auto-backport-of-pr-18191-on-v7.1.x

5. Create a PR against branch v7.1.x, I would have named this PR:

"Backport PR #18191 on branch v7.1.x (Import standard library types at runtime)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the Still Needs Manual Backport label once the PR gets merged.

If these instructions are inaccurate, feel free to suggest an improvement.

p.s. If you can think of a good way to avoid future typing stuff from breaking downstream before merge, please share your ideas.

Agreed this is a tricky problem. The issue isn't that the types aren't valid – they are - but that sphinx et al has a damnable time rendering some types under certain conditions. I'm not sure how we effectively test for that.