Alex Waygood

> The evaluation order at runtime is `key, value, key, value, ...` in source order, matching the new order used in this PR. > > This is perhaps simplest to...

I've taken the changes to the pattern-matching nodes back out again, as @dhruvmanila pointed out to me that they might conflict with some changes around that node being planned in...

> Do we know how the pattern layout will change? Are the changes compatible with the changes we made here or will we end up with a large inconsistency between...

Thanks both!

This seems reasonable to me too. For a stylistic/modernisation rule like this, it can be annoying if it has lots of complaints that can't be autofixed. However, the unfixable complaints...

> Should multiple `Generic[]` case not raise the issue at all then? I'd say _probably_ not. The [behaviour we implemented at flake8-pyi](https://github.com/PyCQA/flake8-pyi/blob/f60d7e3cdc833dd358b493d2ca80fd187cc38cfb/pyi.py#L1762-L1764) is to ignore this rule if `Generic[]` appeared...

(Everything looks great to me now except the autofix code, which I'm still not _quite_ sure about -- both in terms of code readability and in terms of the number...

@tusharsadhwani, I've just pushed https://github.com/astral-sh/ruff/pull/11233/commits/6fce0fd868344efb7e3d4e1336e252fd8f622f35, which gets rid of the remaining `.expect()` and `.unwrap()` calls from `generate_fix()`. Instead, the errors are bubbled up by returning an `anyhow::Result` from `generate_fix()`. In...

We've now made this change in preview mode; we'll be stabilising it in Ruff 0.7. Thanks @calumy!

Yeah I think `from __future__ import annotations` is irrelevant here, _but_ if it's in an `if TYPE_CHECKING` block we should treat it as though it has "stub file" semantics (whether...