Re:Black: An uncompromising Python code formatter
by uryga on Friday May 25, 2018 @09:51PM
(#17159674)
> Black would sometimes change its mind about its own formatting and a second pass would cause a different formatting than the first
Why not? I mean, I never built a formatter so idk about the complexity involved, but to me it seems that if Black had a rule like "if you see `a+b` (no spaces), just leave it alone", applying the rule twice shouldn't change anything.
(though I imagine that the interactions of such rules could become hard to understand...)
Re:Black: An uncompromising Python code formatter
by zestyping on Friday May 25, 2018 @10:02PM
(#17159725)
The whole idea is to _prevent_ people from thinking about formatting, by actually making it impossible to make any formatting decisions. There's exactly one way to format the program and that's it. It's draconian, but that's what's great about it.
Re:Black: An uncompromising Python code formatter
by uryga on Saturday May 26, 2018 @08:07PM
(#17164842)
That's the feeling I got from the readme, but GP sounds like this particular decision was made not so much for 'philosophical' reasons, as because Black-ing a file twice might give different results. I was curious why :)
With this in mind, it has to enforce a rule around operators. Since any operand might be complex, it's more robust to default to spaces around operands always. Otherwise we would inevitably end up hugging operands with an operator that humans consider too tight. And since that's subjective, there is actually no rule that we can hard-code about that.