[refurb] Mark the FURB161 fix unsafe except for integers and booleans

[VascoSch92]

The PR fixes #16457 .

Specifically, FURB161 is marked safe, but the rule generates safe fixes only in specific cases. Therefore, we attempt to mark the fix as unsafe when we are not in one of these cases.

For instances, the fix is marked as aunsafe just in case of strings (as pointed out in the issue). Let me know if I should change something.

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[MichaReiser]

Thanks for looking into this. Could you update the rule's documentation with a ## Fif safety header and explain when the fix is safe (or isn't)? This will also make reviewing easier

[dscorbett]

This PR doesn’t fully fix #16457. The point of that issue is that FURB161 should be unsafe by default, with a few exceptions. This PR keeps it safe by default, the only exception being string literals.

[VascoSch92]

This PR doesn’t fully fix #16457. The point of that issue is that FURB161 should be unsafe by default, with a few exceptions. This PR keeps it safe by default, the only exception being string literals.

Thanks for the explanation. I approved the modification to make the rule unsafe if we can not determine if the argument of the bin method is of type int or bool

[dscorbett]

Using ResolvedPythonType::from would help catch more expressions than literals, like -1 or 1 + 2.

[ntBre]

Thanks for working on this! Overall I think this is good, but we can simplify things a bit by using a fix Applicability, and then I think we can do a better job with type inference with ResolvedPythonType::from, specifically for Expr::BinOp (cases like 1 + 2) and for Expr::UnOp (cases like -1).

If we extend the safe handling to bool, we may also be able to resolve expressions like True or False.

[VascoSch92]

Thanks for working on this! Overall I think this is good, but we can simplify things a bit by using a fix Applicability, and then I think we can do a better job with type inference with ResolvedPythonType::from, specifically for Expr::BinOp (cases like 1 + 2) and for Expr::UnOp (cases like -1).

If we extend the safe handling to bool, we may also be able to resolve expressions like True or False.

Hey @ntBre
I changed to use ResolvedPythonType. Let me know if I used it in the correct way ;-)

[ntBre]

Thanks, it looks good to me!

Let's save this for a follow-up PR like the Expr::Name idea I mentioned above, but I think we can even do better than ResolvedPythonType to handle variable assignments too, like the x = 10 case in the existing tests. There doesn't seem to be an existing is_bool function in our typing module, but we could easily add one similar to is_int:

ruff/crates/ruff_python_semantic/src/analyze/typing.rs

Lines 968 to 971 in 27a315b

	/// Test whether the given binding can be considered an integer.
	pub fn is_int(binding: &Binding, semantic: &SemanticModel) -> bool {
	check_type::<IntChecker>(binding, semantic)
	}

You definitely don't have to work on this, just a couple of ideas if you're interested :)

I pushed two tiny tweaks:

• reverting a couple of lines that just moved around throughout the PR
• adding a little more context to the fix safety docs

I'll merge as soon as CI passes!