Our test pipeline fails any Python service trying to deploy if the black style check fails.
I was initially grumpy about my org adopting black because I preferred single quotes, but the level of standardization is a huge win in my book. I never even think about my code style anymore, I just write it and then run black.
Re:Black – Uncompromising Python code formatter
by meowface on Friday May 17, 2019 @05:41PM
(#19943830)
I've always been a double-quoter, in contrast to most Python devs I know/work with. After we standardized on black, I got some satisfaction seeing all of my coworkers bend to my will (/s).
Re:Black – Uncompromising Python code formatter
by detaro on Friday May 17, 2019 @05:44PM
(#19943850)
How narrow those two choices are! The correct answer is obviously to use single-quotes for keys and key-like cases and double-quotes for values. Make formatters impossible to write! (last sentence very /s, but that style actually exists)
Re:Black – Uncompromising Python code formatter
by kbd on Saturday May 18, 2019 @01:27AM
(#19945835)
That actually seems to be the de-facto Python style. Even Guido said at some point that that's his convention.
Which, as a longtime Go dev and now Rust dev, I love formatters that are opinionated. I don't always love what Gofmt or Rustfmt do, but I definitely like consistency that the community has in code style.
So I don't care what Black thinks - I care what, hopefully, everyone uses. Though, I could see a situation where formatting can be altered and the project has a format config. Meaning that while code fmt differs between projects, it would be consistent among all devs working on X projects.