How to deal with counter-argument to rules? Concrete example PLC1901

[kaddkaka]

The pylint rule PLC1901 (compare-to-empty-string) checks for comparison with empty string which it considers "unnecessary", but I would argue this is not a problem, but rather the reverse!

Example code from documentation:

x: str = ...

if x == "":
    print("x is empty")

Even if the compared object is known to be a string or not, x == "" shows and explain the intent much better than not x.

• If type annotation is missing, or or many lines away, the person reading the code will understand that this variable is meant to be a string. not x does not give any clue on what type x is supposed to be.

Could there be a section "Why is this not bad" in the documentation?

[kaddkaka]

There has been complaints regarding PLC1901 in particular before: #4282 (comment)

[kaddkaka]

Oh, I just found #5264

Is this rule still in "nursery"? Is PLC1901 meant to only be active if explicitly opt-in? I seem to get it just by having select "PL".

Nothing in the rule page documentation hints about this.

[MichaReiser]

Hi @kaddkaka

Thanks for all the research and linking the relevant issues. That's useful.

Yes, the PLC rules aren't for everyone. They encode specific conventions that some find useful. There are many other rules in Ruff that are of a stylistic nature or are rather opinionated. We suggest you freely disable rules if you don't agree with what they're asserting.

[kaddkaka]

@MichaReiser thanks, I agree this is the way to go. In the closed PR it was mentioned that this rule was moved to a "nursery". Does that corresponds to the rules enabled by --preview?

[MichaReiser]

Yes, preview replaced the nursery concept and it is to opt-in to more experimental Ruff features and PLC1901 is one such experimental rule

[kaddkaka]

Would it be valuable to have more rule categories here?

1. rules that are new and not yet battle-tested (they enter in --preview and are moved to stable set of rules when mature)
2. Some rules are considered not good and it's not valuable to include them in the "default" set of rules. these rules should perhaps be stable put "opt-in"

So instead of:

• --preview and stable, have:
• --preview, stable-default, stable-opt-in

[MichaReiser]

Yes, we think that's the long term solution for this. We plan to recategorize rules but haven't gotten around to actually do it. See #1774