⚫ 🔨 Automatically lint with black #605
Conversation
Trigger CI
Trigger CI
cthoyt
changed the title
|
@mberr yes I hope this doesn't cause too many conflicts! It might require copying the config from the @lvermue yup, apparently double quotes are the future. I was against this in the beginning but I gave up my opinion. Many people also didn't like this so much that they harassed the developer of black... not cool at all. Black has a guarantee that the code produces the same AST, so I'm actually very confident without manually checking that it is still the same. black is both deterministic and idempotent (i.e., a fancy word meaning if you run it multiple times in a row it is always guaranteed to be the same as after just running it once). Further, we have a really excellent testing suite here that seems to be happy :) |
|
One question before merging though - do we really want 120 line width or should we go 100 like most of my other projects? Alternatively, we can not specify at all and go with the defaults, which will make them get around 89 (but goes over in reasonable cases) |
I am in favour of wide lines 🙂 if it was only for me, we would stick with one line = one statement, and let your favourite editor do the line breaks with soft wrap, but I am aware that this is a rather unpopular opinion 🤷 |
I suppose it aligns it with the JSON standard and it makes it easier to use contracted words in most languages :) |
IIRC, we are using 120 right now and I'm fine with that |
This PR adds automatic linting with:
blackisortThese changes are guaranteed not to change the abstract syntax tree that python gets, so there are no reasons the code should change how it works at all - it's purely cosmetic. Neither of them look perfect, but they're both automated so we never have to think about how this stuff looks again, which is better in many ways.
Right now the settings are pinned to 120 character line length, but it might actually be better to just use the default (which is a bit shorter)