STY: ignore all existing violations to rule PLR0917 and upgrade ruff to 0.16.x - #20194

@neutrinoceros

But the idea discussed was to enable it in the future #20113 (comment). Maybe "legacy" or "pre-existing" API would be a better term?

I think "legacy" over "historical" may be a good change to help get this PR in?

I intentionally avoided the term "legacy" so as not to imply or suggest all these APIs are meant to be replaced, but I'll settle down for it or any other alternate wording that @saimn can get behind.

Ping @saimn :)

Well it's not about the wording. For what concerns io.fits (but it isn't much different for most subpackages) there is no legacy or historical API, just the current API, that is what it is and will remain like that. And we don't add new API so often. So this comment is wrong (legacy or historical API would suggest that there is a new one), annoying, and useless.

And we don't add new API so often.

the frequency doesn't really matter in my opinion. What does matter is wether we have a consensus that new APIs should not accept a large number of positional arguments. Do we have it ?

Yes it matters. You can't enforce a rule, pollute the code, and declare everything as legacy for a case that almost never happens.

Alright. Putting aside the fact that I explicitly rejected declaring anything "legacy" for the sake of this PR, I'm going to opt-out of this rule for io.fits, hoping that you can lift your objection then.
I also invite anyone interested in avoiding this sort of friction in the future to weigh in on #20519

Hearing the point from @saimn about the APIs, I'm now strongly in favor of removing any additional text in the ignore comment like "historical" or "legacy" or "pre-existing". The API is what it is, and that text is only adding noise.

removed

Pressure is building as ruff 0.17.0 is now out and this change is still needed to upgrade to 0.16.x
I genuinely think @saimn's requests for changes were addressed so, with 3 approvals, I'm considering merging this next week.