Black: An uncompromising Python code formatter • Hacker News Board

Re: Black: An uncompromising Python code formatter

#201

Post by geofft » Sat, May 26, 2018, 3:14 AM UTC

zestyping wrote: post #152

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…

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:…

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

Re: Black: An uncompromising Python code formatter

#202

Post by abiox » Sat, May 26, 2018, 3:25 AM UTC

prawl wrote: post #197

zestyping wrote: post #153

Earlier quoted context omitted.

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.

A double quote is in no way harder to read. Only on Hacker News.

this seems a bit reductive.

Re: Black: An uncompromising Python code formatter

#203

Post by jsmeaton » Sat, May 26, 2018, 3:30 AM UTC

zbentley wrote: post #169

foxhop wrote: post #145

This is so cool. I like all the choices and will be adding it to my workflows for my personal projects.

Choice. There is only one (line length). And I think that's a good thing. Which were you referring to?

I think the commenter likes the choices made by the project so they don't have to make them :)

Re: Black: An uncompromising Python code formatter

#204

Post by nas » Sat, May 26, 2018, 3:52 AM UTC

jsmeaton wrote: post #156

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…

I have to admit that I was very excited to begin enforcing black on all of our projects at work - until the double quotes decision. I’m used to single quotes everywhere (except docstrings!). I’m probably going to still move to black but I know I’m likely to face some pushback now on this one choice, and I don’t yet have the will to defend it. I also know I’m being mostly unreasonable .. “why is this opinionated tool…

The double quotes are the only thing that bother me as well. Double quotes are harder to type (on my keyboards) and look more noisy. All other Black formatting I think I could live with. I suppose I can live with double quotes on strings too but I'm not going to like it. ;-)

Re: Black: An uncompromising Python code formatter

#205

Post by mappu » Sat, May 26, 2018, 3:55 AM UTC

Izkata wrote: post #176

B1FF_PSUVM wrote: post #132

Earlier quoted context omitted.

> Originally PEP 8 had 79 characters. Now that was a weird choice so most companies went with 80 instead Probably thinking of one of these: - backslash continuations - terminals/etc that counted newlines - off by one errors

Also possibly a terminal text editor - the cursor sits on the column where the next character would be input (such as vim's insert mode). So with 79 character lines, the cursor is sitting at 80 while waiting for the next input. If your screen is larger than that it's no big deal, but if your screen is 80 columns and the cursor was at column 81, it would wrap to the next line without actually being a newline.

Also taking up a character, are ASCII-rendered scrollbars (like EDIT.COM and friends).

Re: Black: An uncompromising Python code formatter

#206

Post by ianamartin » Sat, May 26, 2018, 4:36 AM UTC

njharman wrote: post #32

curtis wrote: post #3

> By using it, you agree to cede control over minutiae of hand-formatting. I may be in a minority, but I do not want to cede control over minutiae of hand-formatting. Am I the only person that feels this way?

Why are you interested in minutiae? Esp that which has no functional impact and can be automated. People are into things like this pep8 etc because they don't want to waste another second of their lives thinking about formatting. Or, worse discussing, arguing, bikesheding, documenting, enforcing, teaching the new guy how we format "here". I'm sorry to sound snarky, but this is one of the things you slowly learn over…

Totally agree with this. After having to go through how we do things "here" at a few different jobs, it's just not worth it. It's not worth it when I have to learn someone else's stupid idiosyncrasies, and it's not worth it when I "get" to enforce my own.

I'm willing to let go of the things I'm used to in favor of having something completely uncontroversial. I've been in the business not as long as you, but long enough to count the time lost on this stuff.

We do get attached to style and personalization. I think I was a lot more attached when I was younger at this. Perhaps my formatting was more important when my code itself was less personal or less elegant or something. Or maybe the tasks were simply things that weren't all that interesting but just needed to be done. So my way of leaving my mark was to make the formatting just absolutely perfect. Perhaps it was a way of asserting some agency in junior positions where the architecture was predetermined, the problem was well-defined, and the solution was already known when the ticket was assigned. Just get in there and write the code.

I think--and I may be wrong about this--that as I've gotten older and into roles that are more autonomous, where I get to architect entire components of core company business or start from scratch or do other things that assert my personality and agency in code, I care a hell of a lot less about formatting. Mine, yours, someone else's, I don't fucking care, just forget about it and move on.

I also suspect that caring a lot about code formatting is one of the few ways that juniors can signal that they are really engaged in their work and get a little attention. You can't argue about an application's design or anything actually important, so you push a little on what you can, which is somewhat reasonable, and probably a signal of poor management, really.

Anyway, I digress. Bottom line is that I care less and less as I get older and have other things to worry about. I'm starting to view people who are really picky about personal conventions of code formatting as people who either don't or can't contribute anything more interesting to a conversation.

Re: Black: An uncompromising Python code formatter

#207

Post by G4BB3R » Sat, May 26, 2018, 4:42 AM UTC

Paulo Torrens is crying.

Re: Black: An uncompromising Python code formatter

#208

Post by aphextron » Sat, May 26, 2018, 4:50 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…

Everyone has an opinion, and this is theirs. That's kind of the whole point.

Re: Black: An uncompromising Python code formatter

#209

Post by ianamartin » Sat, May 26, 2018, 4:53 AM UTC

After testing this some tonight, I'm committed to my first-blush response. This is my standard from now on, and it is the standard for my team.

Someone needs to ask a StackOverflow question about Python formatting and we need to answer it with "Just use Black." Upvote the fuck out of it, and be done with this forever.

Re: Black: An uncompromising Python code formatter

#210

Post by hawkice » Sat, May 26, 2018, 5:03 AM UTC

geofft wrote: post #201

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:…

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 bla…

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