RFC: refactor copy argument sanitizing into a unified compat function - #16170

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.

This PR is actually older than the discussion, but I think it still has value in that it prevents that some paths are updated and not others. I could just remove or update the TODO comment to avoid making promises on the future.

Is this still needed? The conclusion to just live with whatever numpy does suggests that all we need to do is update any copy=False defaults to copy=COPY_IF_NEEDED (with the old COPY_IF_NEEDED = False if NUMPY_LT_2_0 else None) and that otherwise code can remain untouched. Or am I missing something?

That was indeed a clear consensus amongst participants in the last dev telecon, however we also agreed that we should ultimately involve downstream stake holders and give them a chance to test different approaches so we can settle for the most aggressive one that doesn't cause too much immediate pain. With this in mind, there are two alternative continuations to this PR:

• API: align default value for copy arguments with numpy at runtime (warn about copy=False) #16174
• API: align default value for copy arguments with numpy at runtime (copy=False raises an error if copies cannot be avoided) #16181

the second one just removes the function I'm introducing here, but the first one creates a deprecation path instead. So, if it turns out downstream players are not affected by the API change, we'll indeed just end up removing this function. However, given the uncertainty, I believe there is still value in having one source of truth instead of multiple instances of this code bits.
I would also argue that it could actually be more work to not merge this one since I'd need to slightly refactor #16174 and #16181 . Nothing too bad, but from where I stand this one is just a button push away from done.

p.s. Not sure what's up with the tests that just seem to be waiting to be run.

I think that's a side effect of merging #15603. If it's blocking I can rebase this one.

I cannot override the statuses, so, yes, maybe best to rebase so we can actually merge...

done

Oh, actually blocked by scientific-python/pytest-doctestplus#242

closing/reopening to retrigger CI now that pytest-doctestplus was updated

OK, thanks, let's get this in so the other two can be rebased...

Thanks Marten ! every child branches is now rebased and conflict-free