Avoid parsing joint rule codes as distinct codes in # noqa - #12809

is_alphanumeric() also allows non-ASCII-digits and letters:

# noqa: A三

Did you mean to use is_ascii_alphanumeric() instead?

Seems reasonable to exclude non-ASCII.

CodSpeed Performance Report

Merging #12809 will not alter performance

_{Comparing charlie/parse (c2e9746) with main (f837428)}

Summary

✅ 32 untouched benchmarks

On that same note, is_whitespace() and trim_start() / trim_end() also handle Unicode whitespace. They should be replaced with is_ascii_whitespace() and trim_ascii_start() / trim_ascii_end(), accordingly.

"ASCII whitespace" is defined as "space, tab, LF, FF, CR". In our case, since Python comments don't allow line breaks, that boils down to just spaces and tabs.

ruff-ecosystem results

Linter (stable)

ℹ️ ecosystem check detected linter changes. (+3 -0 violations, +0 -0 fixes in 2 projects; 52 projects unchanged)

ruff check --no-cache --exit-zero --ignore RUF9 --output-format concise --no-preview --select ALL

+ providers/src/airflow/providers/apache/hdfs/sensors/hdfs.py:45:37: RUF100 [*] Unused `noqa` directive (unknown: `Ignore`)
+ providers/src/airflow/providers/apache/hdfs/sensors/hdfs.py:50:38: RUF100 [*] Unused `noqa` directive (unknown: `Ignore`)
+ providers/src/airflow/providers/google/cloud/hooks/bigquery.py:59:42: RUF100 [*] Unused `noqa` directive (unknown: `Used`)

Linter (preview)

ℹ️ ecosystem check detected linter changes. (+3 -0 violations, +0 -0 fixes in 1 projects; 53 projects unchanged)

ruff check --no-cache --exit-zero --ignore RUF9 --output-format concise --preview --select ALL

+ providers/src/airflow/providers/apache/hdfs/sensors/hdfs.py:45:37: RUF100 [*] Unused `noqa` directive (unknown: `Ignore`)
+ providers/src/airflow/providers/apache/hdfs/sensors/hdfs.py:50:38: RUF100 [*] Unused `noqa` directive (unknown: `Ignore`)
+ providers/src/airflow/providers/google/cloud/hooks/bigquery.py:59:42: RUF100 [*] Unused `noqa` directive (unknown: `Used`)

But Python comments can contain non-ASCII whitespace? We already have an is_python_whitespace that respects the spec for tokens: https://docs.python.org/3/reference/lexical_analysis.html#whitespace-between-tokens

But Python comments can contain non-ASCII whitespace?

Fair enough, though I still don't see why someone would want to use non-ASCII whitespace in the noqa part of a comment. A user might want to write an explanation in their native language in the same comment, sure, but noqa and the rule codes are never localized.

One more thing: ParsedFileExemption::try_extract() currently treats A001 , B002 (whitespace before comma) and A001,,B002 (empty slot) as if B002 doesn't exist. Is this difference in behaviour intended?