RUF027: Consider ignoring strings that consist solely of a single placeholder

[JortdeBokx]

Issue

I believe RUF027 produces a false positive (or at least an over-eager suggestion) when a string literal consists entirely of a single name in curly braces (e.g., "{variable}") and that name happens to be in scope.

Proposed change

Refine the RUF027 heuristic such that among the other checks, it also ignores string that:

• Start with '{' and end with '}'
• Have no format specifier ('.2f')
• Contain no text outside of that single set of braces.

So:

foo = 3.14159
bar = "I have {foo} foos"  # ✅ RUF027 triggers (contains prose)
baz = "{foo:.2f}"          # ✅ RUF027 triggers (contains format specifier)
foo_tag = "{foo}"          # ❌ RUF027 ignores (simple name)

Context

I was writing some code that handles UCUM units. One part was responsible for creating an object containing a unit and value for very specific (medical) UCUM units containing just annotations. UCUM annotations are placed between curly braces.

UCUMunit: Literal["mg", "mL", ..., "{platelets}", "{RBC}"]

class UCUMMeasure:
    value: float
    unit: UCUMunit

def parse_some_measurement(platelets: float) -> UCUMMeasure: 
    ... 
    value = platelets
    unit = "{platelets}"  # <- RUF027 
    return UCUMMeasure(value, unit)
    

Discussion

On the one hand the current linting rule is inconvenient when you are trying to write literal strings which happen to contain a variable name between curly braces.
On the other hand, if you want to explicitly convert a variable to a string using f-strings and happen to forget the f prefix, this linting rule should capture it. Then again, you might want to use str() instead. I think converting variables to strings by using an f-string with a single expression an no other text occurs less often than using some string literal with curly braces.

While I could use a noqa comment, I believe this pattern is common enough in templating and scientific units that a change to the rule's heuristic would yield a more generic solution.

[MichaReiser]

Thanks for the detailed write-up and for including the relevant context.

I'm leaning towards keeping this as. I'd consider it more common that someone meant to use an f-string here (even if using str might be preferred) and suppressing the few instances where this is a false-positive with a noqa seems very reasonable.