Pre-commit autoupdate

[nstarman]

Following #16396

Note that autoupdate_commit_msg doesn't appear to have a way to set the message body. Normally in git this can be done with a second -m or a -a.

[github-actions]

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.

[pllim]

I think this is okay but then again, this is also io.fits, better see if @saimn or @astrofrog are okay with this first.

[astrofrog]

Just curious, why is this not just {k}?

[neutrinoceros]

!r calls repr instead of str, which is sometimes desirable and in particular will put strings in quotes. Here it's a strictly equivalent refactor.

[nstarman]

I'm happy to change it, I was just keeping this strictly translated. But yes, {k} is equivalent.
IMO I don't sweat these (unless for line length) and I'm just waiting for ruff to eventually decide in one direction or another and auto fix everything with a pre-commit autoupdate. IDK why they haven't yet. A quick google found no discussion of this. Perhaps I'm missing a subtlety where f"{k}" and f"{k!r}" aren't actually equivalent. https://docs.astral.sh/ruff/rules/explicit-f-string-type-conversion/#why-is-this-bad talks about custom __format__, so maybe?

[neutrinoceros]

Perhaps I'm missing a subtlety where f"{k}" and f"{k!r}" aren't actually equivalent.

They only appear equivalent for types that implement either __str__ or __repr__ but not both (because they default to each other). They are not the same in the str type.

[pllim]

Now I am confused. Do we change to {k} or not? Reading https://stackoverflow.com/questions/33097143/what-is-the-difference-between-r-and-r-in-python just makes me even more confused.

[eerovaher]

Have you looked up any explicit examples?

>>> greeting = "Hello!"
>>> print(f"{greeting}")
Hello!
>>> print(f"{greeting!r}")
'Hello!'

UPDATE: and the equivalent example using the old-style string formatting:

>>> greeting = "Hello!"
>>> print("%s" % greeting)
Hello!
>>> print("%r" % greeting)
'Hello!'

[neutrinoceros]

This PR is meant to refactor code, not change behavior, so we should stick with{k!r}.

[pllim]

OK then, let's merge. Thanks, all!