UP037: autofix removes quotes from Literal["value"] typing when not imported

[Prometheos2]

UP037's autofix removes quotes from typing.Literal["value"] when Literal is not imported, but it's supposed to have str values.

_DTYPE_BACKEND: Literal["pyarrow", "numpy_nullable"]

turns into

_DTYPE_BACKEND: Literal[pyarrow, numpy_nullable]

Details

• Version: 0.0.286
• Relevant settings: select = ["UP"]
• Commands producing the bug:
  • the VSC extension's autofix
  • ruff . --fix
  • ruff . --fix --isolated --select UP

[charliermarsh]

Is it a mistake or intentional that Literal is not imported?

[Prometheos2]

It was a mistake.

(Admittedly, it was a bit of both. I was trying out Ruff's autofix on save on VSC.)

[zanieb]

The problem here is that we cannot identify Literal as typing.Literal if it's not imported. We could add an exception for this to avoid false positives but it could introduce false negatives. Perhaps we can just avoid applying this fix (or reduce the applicability) if there's not a binding for the name of the subscript?

[charliermarsh]

Yeah this is largely "working as intended" in that if we can't resolve a symbol to typing.Literal, then we treat values within subscripts in type annotations as type annotations themselves (typing.Literal is an exception).

I suppose we could change the logic to avoid treating values within subscripts as annotations if the subscript itself is unbound, although it would do the wrong thing if the user has any wildcard imports.

[zanieb]

Perhaps we can downgrade from automatic to suggested fix if it's unbound. The wildcard imports are a good example, but hopefully not too common in this case?

[zanieb]

I'm not sure how to implement this with the way that we visit type definitions — do you have a suggestion @charliermarsh ?

[charliermarsh]

@zanieb - What if we just treat "Literal" as typing.Literal if the symbol is unresolved...?