Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rule duplication F509 and PLE1300 #11403

Open
Tracked by #2714
dhruvmanila opened this issue May 13, 2024 · 7 comments
Open
Tracked by #2714

Rule duplication F509 and PLE1300 #11403

dhruvmanila opened this issue May 13, 2024 · 7 comments
Labels
rule Implementing or modifying a lint rule

Comments

@dhruvmanila
Copy link
Member

Both rules check for invalid format character in % format style string.

The implementation is almost the same:

F509

match pyflakes::cformat::CFormatSummary::try_from(value.to_str()) {
Err(CFormatError {
typ: CFormatErrorType::UnsupportedFormatChar(c),
..
}) => {
if checker.enabled(Rule::PercentFormatUnsupportedFormatCharacter) {
checker.diagnostics.push(Diagnostic::new(
pyflakes::rules::PercentFormatUnsupportedFormatCharacter {
char: c,
},
location,
));
}
}

PLE1300

// Parse the format string (e.g. `"%s"`) into a list of `PercentFormat`.
if let Err(format_error) = CFormatString::from_str(string) {
if let CFormatErrorType::UnsupportedFormatChar(format_char) = format_error.typ {
checker.diagnostics.push(Diagnostic::new(
BadStringFormatCharacter { format_char },
expr.range(),
));
}
};

There's one difference which can be noticed when an implicitly concatenated string is used. F509 looks at the concatenated string while PLE1300 looks at each part of an implicitly concatenated string. Refer to https://play.ruff.rs/6efd9945-2a3b-43e4-b9b7-a8d041b98318.

Reference:

@dhruvmanila dhruvmanila added the rule Implementing or modifying a lint rule label May 13, 2024
@charliermarsh charliermarsh added this to the v0.5.0 milestone May 13, 2024
@charliermarsh
Copy link
Member

@dhruvmanila - Let's remove PLE1300 as part of v0.5.0?

@zanieb
Copy link
Member

zanieb commented May 13, 2024

See #9756 for prior art.

@dhruvmanila
Copy link
Member Author

Let's remove PLE1300 as part of v0.5.0?

Yeah, that makes sense but there's one difference where PLE1300 would check each part of an implicitly concatenated string while F509 checks it as a whole. This means that the number of diagnostics would be reduced. That said, I think F509 can be improved to either

  1. Include all the invalid characters in the message or
  2. Raise violation for each invalid character and highlighting the part of the string instead of the entire string

@dhruvmanila dhruvmanila self-assigned this Jun 25, 2024
@dhruvmanila
Copy link
Member Author

I'm looking into this and it seems that there's one behavior which is different - PLE1300 looks at both % style strings and .format strings while F509 only looks at % style strings. Basically, F509 is a subset of PLE1300 which means we should remove F509 instead.

@Pierre-Sassoulas
Copy link
Contributor

Shouldn't they be aliased to match what's expected from each tool and not break rétro compatibility ? (There's another issue for human readable names where old_names from pylint and aliases came up).

@dhruvmanila
Copy link
Member Author

Yeah, sorry, I meant that F509 will redirect to PLE1300 similar to #9756

@dhruvmanila dhruvmanila linked a pull request Jun 25, 2024 that will close this issue
@dhruvmanila
Copy link
Member Author

dhruvmanila commented Jun 25, 2024

We've decided to not do this via rule redirection but wait until rule re-categorization (#1774) is complete and merge these rules instead. Refer to #12020 for context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rule Implementing or modifying a lint rule
Projects
None yet
Development

No branches or pull requests

4 participants