PLR6301 probably shouldn't recommend static methods

[NeilGirdhar]

If I remember correctly, Guido once suggested that adding static methods to Python was a mistake. Whether or not that's apocryphal, I do think that Ruff shouldn't be recommending converting methods to static methods, which this rule does.

Static methods are often preferred to bare functions because they enclose the name in the class namespace. And they're preferred to ordinary methods when you want to be able to call them without a reference to self. The problem with static methods is that they do not respect polymorphism when they are overridden in subclasses. Thus, I think they should usually be avoided and classmethods should be preferred.

Suggestion for rule PLR6301: Change the message from "could be a function or static method" to either:

• "could be a function or class method"
• "could be a function, static method, or class method"

In Ruff's documentation, it might be helpful to provide guidance. (After all, Ruff makes us all better programmers with its gentle nudges, why not provide guidance too?) We can highlight general principles to pick each solution:

• class methods should be preferred if they may be overridden in subclasses (since bare and static methods do not respect polymophic calls),
• otherwise bare functions are preferable for most functions,
• in rare cases where the function belongs in the class namespace, then static methods are acceptable.

I will probably disable the rule regardless since I tend to prefer ordinary methods for maximum flexibility when inheriting, and use classmethods mainly for factories and for methods called by factories.