Request: Raise error on any printf style formatting for direct string interpolation

[Avasam]

As explained here: #3549 (comment) , Ruff cannot safely autofix all usages of printf-style-formatting (UP031).

I would still like cases like "%s" % may_be_a_single_element_tuple to be raised, as they can be manually fixed.
I don't mind whether this is done through UP031 or as another rule (could be in FLY, see #2102 (comment)).

[charliermarsh]

I think this is a reasonable change. I'd love to get more opinions on it.

[Avasam]

This likely now relates to #3863/#7769 (fixable groups/fix applicability).

You may still want to split it in a different rule to separately configure "fixable w/o type information" vs "unfixable (bad argument count)/risky fix". Idk.

In my case I'm looking to refactor out print-f style formatting. And prevent using it in new code across my projects. The following risky fix is acceptable during the refactoring phase (under the understanding it is a risky fix and needs review, but can be fixed later if missed during testing):

world = ("World",)
print("Hello %s" % world)
>>> Hello World

print(f"Hello {world}")
>>> Hello ('World',)

[zanieb]

Hey @Avasam the applicability (safety level) is attached to the fix not the rule so we could generate an always applicable fix when type information is around but a sometimes applicable fix when not. Does that address your case?

[Avasam]

As far as the original post goes. I really just want to prevent printf formatting and raise location in CI . Autofix or not.

As far as autofixing goes. It'd be a nice to have for me if printf-style strings are updated even if it causes the constructed string to change. My last comment is just because I think those two features are likely related.

[zanieb]

I'd be happy to review a pull request that changes this rule to raise a violation when type information cannot be inferred. We should gate this behavior behind preview mode. We can explore an unsafe fix after.

[MichaReiser]

Ruff 0.8 now flags all format string usages, see #12461