Black: An uncompromising Python code formatter • Hacker News Board

Re: Black: An uncompromising Python code formatter

#151

Post by abaldwin7302 » Fri, May 25, 2018, 9:07 PM UTC

ambivalence wrote: post #108

abaldwin7302 wrote: post #93

Is this conceptually different from using pylint, failing the build for any warnings and saying anyone who modifies the `pylintrc` file gets fired?

Sounds like you're joking but I'll bite. Yes, it's different because doing what you suggest introduces barriers for people which make landing changes harder. By forcing people to conform to any style manually, especially by blocking them from landing important features and bug fixes due to styling preferences, you are building up opposition. It's just a bad experience for everybody involved. In contrast, when you're…

Agreed auto-correct is a big plus. Maybe a better way to phrase my question is this: Can auto-correct be implemented in pylint? Or does allowing configurations create too much of an obstacle?

In the ruby world for example, rubocop has an auto-correct feature. However it is only implemented for a subset of the style checks.

Re: Black: An uncompromising Python code formatter

#152

Post by zestyping » Fri, May 25, 2018, 9:11 PM UTC

ambivalence wrote: post #84

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…

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: 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!)

Re: Black: An uncompromising Python code formatter

#153

Post by zestyping » Fri, May 25, 2018, 9:22 PM UTC

ambivalence wrote: post #115

mixmastamyk wrote: post #109

Earlier quoted context omitted.

Double quotes also have drawbacks, visual noise and the doubling of keypresses required on the most common keyboard layouts.

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.

Re: Black: An uncompromising Python code formatter

#154

Post by iainmerrick » Fri, May 25, 2018, 9:40 PM UTC

ljm wrote: post #106

In case of credit where credit’s due, is gofmt where the concept of auto-formatting syntax became mainstream? At first I hated it because I thought I had a style, but later on I enjoyed the consistency far more than I enjoyed my signature approach. A programming language has an opinion on how you build software with it, so it’s appreciated that it also has an opinion on how you should write it so that it remains cons…

Go is probably where it went mainstream in the current generation, yeah, but the idea has definitely been around for a while.

The earliest implementation I know of was COMAL, a very clean and tidy version of BASIC, I think dating from around 1980.

A lot of 80s micro BASICs did some level of auto-formatting purely as a side-effect of the source code being stored in tokenized form to save memory.

Re: Black: An uncompromising Python code formatter

#155

Post by ben509 » Fri, May 25, 2018, 9:52 PM UTC

mixmastamyk wrote: post #109

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…

Double quotes also have drawbacks, visual noise and the doubling of keypresses required on the most common keyboard layouts.

I agree about the noise, but, it's much easier to work with. raise FooException("Can't load bar") works, as does f"The flange is elevated by {flange['spronge']} degrees of spronge."

Re: Black: An uncompromising Python code formatter

#156

Post by jsmeaton » Fri, May 25, 2018, 9:58 PM 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…

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 not perfectly aligned with MY opinions??” .. but feelings.

Re: Black: An uncompromising Python code formatter

#157

Post by toyg » Fri, May 25, 2018, 10:04 PM UTC

hrez wrote: post #135

What's with python 3.6 requirement? - Major stable distros are at python 3.5. So I can't even try it without messing with system python or OS.

Probably because of f-strings.

Re: Black: An uncompromising Python code formatter

#158

Post by biztos » Fri, May 25, 2018, 10:10 PM UTC

ljm wrote: post #106

In case of credit where credit’s due, is gofmt where the concept of auto-formatting syntax became mainstream? At first I hated it because I thought I had a style, but later on I enjoyed the consistency far more than I enjoyed my signature approach. A programming language has an opinion on how you build software with it, so it’s appreciated that it also has an opinion on how you should write it so that it remains cons…

In the Perl world auto-formatting syntax is old hat, though of course (it being Perl) the formatter is highly configurable[0]. So in practice you get consistency within an organization, but perhaps not over time.

Coming from that background I was initially put off by the lack of options with gofmt, but once I realized the whole world of go coders would be using the same formatting I immediately fell in love with it.

[0]: https://metacpan.org/pod/distribution/Perl-Tidy/bin/perltidy

Re: Black: An uncompromising Python code formatter

#159

Post by makapuf » Fri, May 25, 2018, 10:12 PM UTC

fishywang wrote: post #128

On the example there's: # in: TracebackException.from_exception(exc, limit, lookup_lines, capture_locals) # out: TracebackException.from_exception( exc, limit, lookup_lines, capture_locals ) I don't like this one. I would prefer that if you have )/]/} on the next line, then you should have a trailing comma, e.g.: TracebackException.from_exception( exc, limit, lookup_lines, capture_locals, ) Also I would prefer one-pe…

Sure you can prefer this but it is not the point. The point is that having ONE average way to do it > several best ways for several people.

Re: Black: An uncompromising Python code formatter

#160

Post by ben509 » Fri, May 25, 2018, 10:14 PM UTC

ambivalence wrote: post #31

aagimene wrote: post #27

Earlier quoted context omitted.

> It's not configurable. Except for the line length: > if you're paid by the line of code you write, you can pass --line-length with a lower number.

Yeah, I wasn't willing to die on that hill, especially that I'm introducing a new default value that wasn't popular before.

It was a good call. Some code bases use long identifiers and an 80 column limit gets to be a mess.

And for the 80 column fetishists, you'd have to pry their VT-100 terminals from their cold, dead hands. Disposing of the body is enough of a pain, but worse, you have to find a recycler who can deal with the lead glass in the CRT.