I think whitespace is an I important tool in making code readable. Just like we used paragraphs in writing normally. Camelcase also lends itself to long variable, making lines or code longer and more difficult to read sometimes.
I do agree that it can become cumbersome if the goal to alig everything. Instead I would argue that the time spend is worth it, if the changes do promote readability.
Readability is subjective though. My suggestion is not intended to create a mandate, but to allow alignment when it makes sense.
Yes, I agree. But that doesn’t mean that columnizing the equals signs makes code more readable. (Personally, I think it doesn’t.)
However, I don’t think anyone is saying that all code should be columnized in that way. And you already have the freedom to do it in your code if you want to.
As far as I am aware, the current PEP 8 text has nothing to do with that feature (whether for trailing comments, for assignment statements, or both) being missing from ruff, it’s only missing because it’s hard to design a robust mechanism for clearly specifying such alignments that an autoformatter can understand while still looking reasonable when reading the code.
In the meantime, selective disagreement with the autoformatter output and linter results is precisely why all the autoformatters provide options to disable them for designated code sections, and why all the linters provide ways to disable specific alerts: because they’re general tools, and not always correct in specific cases.
I would prefer this type of visual alignment was done in an IDE similar to soft line breaks. Doing it in the source code creates noise in the git history.