Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Black: An uncompromising Python code formatter

github.com

Post reply on HN
Print view View original

131–140 of 262 posts

Re: Black: An uncompromising Python code formatter

#131

Post by sametmax »

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…

When i heard about gofmt, i hated it. I wanted choice. Then i realised i loved python because it forced people to indent. I gave black a try. I still hate some style decisions, but who cares ? The benefits are far too great to pass up.

Re: Black: An uncompromising Python code formatter

#132

Post by B1FF_PSUVM »

ambivalence wrote: post #42
crooked-v wrote: post #20

88 characters per line is a weird choice. Why not 90?

Originally PEP 8 had 79 characters. Now that was a weird choice so most companies went with 80 instead, including Facebook. You want a low-ish limit because it makes it possible to fit two files side by side on a typical screen resolution. Even if you don't edit like that, you look at diffs like that. More importantly, a low column limit is helpful to disabled engineers who don't have to navigate horizontally so much…

> 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

Re: Black: An uncompromising Python code formatter

#133

Post by breckuh »

pomber wrote: post #76
vjeux wrote: post #6

At Facebook, we are now using prettier[1] on all our JavaScript files, a growing number of Hack files are formatted with Hackfmt[2] and now black is being rolled out for Python. It's a really exciting time :) [1] https://prettier.io/ [2] https://github.com/facebook/hhvm/blob/master/hphp/hack/src/h...

Prettier is what I miss more everytime I switch from JS to Python. I hope Black fixes that.

I feel the same way. Prettier is a dream--instant speed, great output and 100% reliability for over a year.

So far black seems great. I just ran it on some existing Python packages and it was fast and the output was correct. Still need to try the editor plugins but very excited so far.

Now, if only someone would lead a similar project for R. :)

Re: Black: An uncompromising Python code formatter

#134

Post by fishywang »

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…

PEP8 doesn't have a preference between single or double quotes. Black has:

> It will replace the latter with the former as long as it does not result in more backslash escapes than before.

And I think that's good enough (and in compliance with PEP8)

Re: Black: An uncompromising Python code formatter

#136

Post by ComputerGuru »

Inityx wrote: post #130
woolvalley wrote: post #121

Earlier quoted context omitted.

Eh, many programming languages use double quotes for strings, and single quotes for singular characters. Languages that can use single quotes for strings that I know of are ruby and python.

And even then, Perl and Ruby (heck, even Bash) have a semantic difference between double- and single-quoted strings. The only other popular general-purpose languages where they're synonymous are PHP, JavaScript, and Lua.

>The only other popular general-purpose languages where they're synonymous are PHP, JavaScript, and Lua.

PHP does treat single and double quotes differently. Contents of single quotes strings are not parsed for variable substitution.

Re: Black: An uncompromising Python code formatter

#137

Post by ambivalence »

lambda wrote: post #119
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…

Hmm. My reading of PEP 8 on slices is that the spaces surrounding : in slices are optional, and used to implement the later rule "If operators with different priorities are used, consider adding whitespace around the operators with the lowest priority(ies). Use your own judgment; however, never use more than one space, and always have the same amount of whitespace on both sides of a binary operator." This leads to th…

Black does not take existing formatting into account. Doing so would cause non-deterministic formatting (Black would sometimes change its mind about its own formatting and a second pass would cause a different formatting than the first).

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.

Re: Black: An uncompromising Python code formatter

#138

Post by ComputerGuru »

woolvalley wrote: post #121
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.

Eh, many programming languages use double quotes for strings, and single quotes for singular characters. Languages that can use single quotes for strings that I know of are ruby and python.

Don’t forget VimL, the language that insanely decided to use double quotes as a “start of comment” indicator, then went back and gave them special meaning based on their position so they either signal the start of a comment or a string.

Re: Black: An uncompromising Python code formatter

#139

Post by ComputerGuru »

vjeux wrote: post #6

At Facebook, we are now using prettier[1] on all our JavaScript files, a growing number of Hack files are formatted with Hackfmt[2] and now black is being rolled out for Python. It's a really exciting time :) [1] https://prettier.io/ [2] https://github.com/facebook/hhvm/blob/master/hphp/hack/src/h...

Wow, that website is hard to use! You can’t touch scroll down on iOS unless you click towards the bottom of the page as scrolls in the animation zone are ignored.

Re: Black: An uncompromising Python code formatter

#140

Post by ComputerGuru »

demosito666 wrote: post #120
waleedka wrote: post #113

Earlier quoted context omitted.

One idea you might want to consider is to create a global function, let’s call it h() and pass all your human readable strings through it, like so h(“hello world”). This function, simply returns the same string. This is more explicit than relying on quote types. It also allows you to do interesting things such as logging everything to a text file and running a spell checker on it, or checking for wrongly encoded stri…

I believe _() would be even better, granted you might want to translate messages in future. At first might just def _(s): return s.

A single underscore is pretty much de facto reserved for localization.
Post reply on HN