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

Good catch, thank you !
This rule alone has about 1000 violations so I'll keep it ignored for now.

Out of curiosity, do you know what the difference is between just adding _ignore_s and using the @typing.override Ruff suggests for some cases?

I'm not aware of this suggestion nor did I see it at any point going through a limited subset of ruff's diagnostics. Could you give an example of it ?

Can you add PLR0917 to ignore list of **/tests/* since pytest fixtures appear to static analyzers as positional arguments, but pytest handles them as kwargs. That should reduce the number of ignore comments by a lot.

I'm not aware of this suggestion nor did I see it at any point going through a limited subset of ruff's diagnostics. Could you give an example of it ?

I haven't checked here, but this is e.g. what the glue-core auto-update brings up. Apparently only applies to functions redefined in subclasses.

Oh I see.
As per the docs

This rule exempts methods decorated with @typing.override. Changing the signature of a subclass method may cause type checkers to complain about a violation of the Liskov Substitution Principle if it means that the method now incompatibly overrides a method defined on a superclass. Explicitly decorating an overriding method with @override signals to Ruff that the method is intended to override a superclass method and that a type checker will enforce that it does so; Ruff therefore knows that it should not enforce rules about methods having too many arguments.

I thought we were only going to modify pyproject.toml but okay...

I don’t think this comment is of any use whatsoever, arguments won't disappear in the near or far future, so just add a global exclude please.

ruff: ignore[PLR0917] historical API

But the idea discussed was to enable it in the future for newly added functions. Maybe "legacy" or "pre-existing" API would be a better term?

In case not all subpackage maintainers come to an agreement on the ignores, should those get a per-package exception in pyproject.toml or .ruff.toml?
Or, as an alternative compromise, have you checked how many violations remain with max-positional-args increased to 7 or 8? Seems a good deal of definitions already explicitly using the posargs, *, namedargs syntax have that many.
(Just checked locally; for 7: 116 out of 305 remaining, for 8: 77)

Here's what I got on current main

so the number of violations is roughly divided by 2 for each additional slot allowed-positional up to 5, then it goes off more slowly. I personally think we should aim for 3 to 4 for new functions, and that 5 is a very decent default for a large and old code base such as astropy.

The old code base is not really a concern here since the existing functions will remain exempt anyway. But I also think 3-5 is a good recommendation for new functions in general. And to any new function where a larger number seems justified, the comment could still be added.