Black: An uncompromising Python code formatter

Post by zestyping » Sat, May 26, 2018, 2:06 AM UTC

Shish2k wrote: post #166

zestyping wrote: post #152

Earlier quoted context omitted.

Slices: My reading of README.md is that Black inserts spaces around the colon, is that right? Almost none of the Python I've seen in 20+ years is written that way. The tutorial and documentation on python.org don't use spaces around the colon, and it is extremely rare in the standard library (out of over 1100 slice expressions that have operands on both sides of a colon, I count 10 that use the extra spaces). Quotes:…

> My reading of README.md is that Black inserts spaces around the colon, is that right? I can't speak for the readme, but: $ cat test.py x = [1,2,3] print(x[1: 3]) $ black test.py reformatted test.py $ cat test.py x = [1, 2, 3] print(x[1:3])

Post by weberc2 » Sat, May 26, 2018, 2:07 AM UTC

zestyping wrote: post #188

ambivalence wrote: post #84

Earlier quoted context omitted.

Colons in slices are implemented to the letter of PEP 8. Your disagreement here probably stems from pycodestyle mistakenly enforcing a different rule (no spaces before colons on if-statements, defs, and so on) in the slice context. The language itself doesn't have an established standard in terms of string quote usage. If it did, Black would follow it. What repr() does is a weak indicator and how the documentation is…

I thought of another way to express this that might resonate better. What I like about the Black philosophy is that it wants to make code style _uninteresting_. People should think about other things, not formatting. That's a great goal. So it seems to me that the best style choice is the most _boring_ choice. The least creative, least novel way. It should try to avoid inventing new formatting algorithms. What's the…

Post by [deleted] » Sat, May 26, 2018, 2:34 AM UTC

zestyping wrote: post #68

This is great except for the enforcement of double-quotes around all strings and spaces around slice operators. These two choices contradict the standard Python documentation, most of the standard library, and the behaviour of the interpreter itself. When the language itself has an established convention, Black should follow that convention, not fight it. These two weird choices just generate needless churn, which is…

Post by prawl » Sat, May 26, 2018, 2:34 AM UTC

zestyping wrote: post #153

ambivalence wrote: post #115

Earlier quoted context omitted.

You can still type single quotes. You have a tool to convert that for you. The visual noise complaint is interesting. Do you also consider the letter W to be more noisy than the letter V? Should we discourage the use of noisy letters in the alphabet?

A double-quote is more noisy than a single-quote, and W is more noisy than V. The difference is that " and ' are equally usable options in the context we're talking about. Quotes are very common, so the visual noise adds up when your screen is full of quote marks. Given that they mean the same thing, and one is both harder to type and harder to read, it makes sense to prefer the other.

Post by yycom » Sat, May 26, 2018, 2:42 AM UTC

zestyping wrote: post #194

yycom wrote: post #182

Earlier quoted context omitted.

> And if you can't depend on it, why have it? That's a bit rich. There are other conventions in programming that you can't depend on technically but serve a real purpose. Identifier naming and comments are the first that come to mind. If a language gives you a choice of token that has no semantic distinction then different people will adopt different semantics by convention. As an aside, calling a tool "opinionated"…

Sometimes it's helpful just to have a decision; any decision, followed consistently, is better than no decision or continued debate. This is one of those situations. So I don't read "opinionated" to necessarily mean "better than your opinions"; it's more like "makes decisions for you so you can avoid the cost of debating them."