Black: An uncompromising Python code formatter

Re:Black: An uncompromising Python code formatter by zestyping on Friday May 25, 2018 @05:11PM (#17158016)

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: We have a difference of opinion over what constitutes an established convention. If the language's own way of displaying strings has been stable for its entire history, I consider that established. A reasonable choice would have been to do what repr() does (single-quotes unless the string contains a literal single-quote) or a simplified version of it (single-quotes always), not the opposite of what the language itself does.

(I wouldn't care so much about this except that I've really wanted a tool like Black for a while and greatly appreciate the philosophy!)

[ Parent | on HN ]

Re:Black: An uncompromising Python code formatter by Shish2k on Friday May 25, 2018 @06:43PM (#17158741)

> 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])

[ Parent | on HN ]

Re:Black: An uncompromising Python code formatter by zestyping on Friday May 25, 2018 @10:06PM (#17159745)

Oh, I must have misunderstood. Sorry! I take back my issue with the slices, then.

[ Parent | on HN ]

Re:Black: An uncompromising Python code formatter by geofft on Friday May 25, 2018 @11:14PM (#17159982)

The README confused me, but I think it's saying that it inserts spaces if needed to make it clear that it's a lower-precedence operator. But unlike operators like +, it's not one that inherently requires spaces.

I tried out black and it does the following (the file originally had no spaces):

    x = a + b
    x = m[a:b]
    x = m[a + 1 : b]
    x = m[a:-b]
    x = m[a : 1 - b]

I would personally still write m[a + 1:b], I think, but black's approach is totally defensible. (I guess I would really write m[a+1:b], and black would rightly correct me.)

[ Parent | on HN ]

Re:Black: An uncompromising Python code formatter by jwilk on Saturday May 26, 2018 @06:02AM (#17161210)

m[a+1:b] and f(x=y+1) are weird corner cases of Python formatting.

I usually avoid this problem by adding extra parentheses:

  m[(a + 1):b]
  f(x=(y + 1))

[ Parent | on HN ]

Re:Black: An uncompromising Python code formatter by hawkice on Saturday May 26, 2018 @01:03AM (#17160311)

Wouldn't being closer imply being used together by the operator? So: 6/2 * 3 = 9 but 6 / 2*3 = 1? In the slice context it seems very obvious the colon has to be slicing, because it can't stand alone to produce an indexable value. But spacing should use this rule, right? [I think this rule was the one used by fortress, the Guy Steele language?]

[ Parent | on HN ]

Re:Black: An uncompromising Python code formatter by geofft on Saturday May 26, 2018 @03:08AM (#17160626)

Yes, that's the rule black is implementing (assuming I'm reading your comment right and understanding its README right...). m[a + 1:b] is in danger of being read as "take the slice 1-to-b, add it to a, index m on that" - even though we know that isn't a well-typed set of operations, the spacing implies that's how it should be read, same as e.g. m[a + 1/b].

Spacings that don't conflict with precedence are m[a+1:b], m[a+1 : b], or m[a + 1 : b]. While the middle one makes precedence obvious, all three are acceptable. black picks the latter, and I think it picks that one because of another rule that it should prefer writing a + 1 instead of a+1.

[ Parent | on HN ]