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

171–180 of 262 posts

Re: Black: An uncompromising Python code formatter

#171

Post by fishywang »

makapuf wrote: post #159
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.

I'm saying this is a weird/below-average way to do it.

If this cannot fit in one line:

    foo(arg1, arg2)
My first choice would be:

    foo(
        arg1,
        arg2,
    )
Second choice would be:

    foo(
        arg1, arg2,
    )
While Black chooses:

    foo(
        arg1, arg2
    )
And made some unconvincing argument about it:

> Unnecessary trailing commas are removed if an expression fits in one line. This makes it 1% more likely that your line won't exceed the allotted line length limit. Moreover, in this scenario, if you added another argument to your call, you'd probably fit it in the same line anyway. That doesn't make diffs any larger.

Who cares about the 1% chance of not exceeding the line length limit, really?

Re: Black: An uncompromising Python code formatter

#172

Post by acdha »

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.

That's been my experience. I'm using the VSCode plugin and have for the first time ever enabled format-on-save for Python. I have yet to have any reason to see that as anything other than a positive.

Re: Black: An uncompromising Python code formatter

#173

Post by mixmastamyk »

ben509 wrote: post #155
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.

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

Goes both ways, sometimes there's text to quote:

raise KeyError('"%s" not found.' % name)

f'The flange is elevated by {flange["spronge"]} degrees of spronge.'

I don't normally use many contractions or possessives in my code, but am willing to admit it happens occasionally.

Re: Black: An uncompromising Python code formatter

#174

Post by mixmastamyk »

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.

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

Nailed it.

Re: Black: An uncompromising Python code formatter

#175

Post by stevesimmons »

kstrauser wrote: post #80
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…

That's the #1 complaint I have (and hear) about Black. Everything else, I can live with. And honestly, I can live with using double quotes everywhere, especially when I can type single quotes and then let it re-write them. It's just that they currently look really, really odd to me because that's not how Python is traditionally written.

I prefer a quoting convention of single quotes for text identifiers (as they rarely contain quotes) and double quotes for English text (because contractions are common). Thus:

    key['first_name'] 
    print("Isn't this clearer?")

Re: Black: An uncompromising Python code formatter

#176

Post by Izkata »

B1FF_PSUVM wrote: post #132
ambivalence wrote: post #42

Earlier quoted context omitted.

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

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.

Re: Black: An uncompromising Python code formatter

#177

Post by jedberg »

ComputerGuru wrote: post #140
demosito666 wrote: post #120

Earlier quoted context omitted.

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.

Which is exactly what this is. Putting everything a human reads into a function is step one of localization.

Re: Black: An uncompromising Python code formatter

#178

Post by ciupicri »

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.

Also Pascal and SQL.

Re: Black: An uncompromising Python code formatter

#179

Post by ambivalence »

fishywang wrote: post #170
ambivalence wrote: post #36

Earlier quoted context omitted.

What don't you like about the exceptions? The code and the documentation would both be simpler without them. They are there because the end result is closer to what a human would do in those situations. And the two exceptions you mentioned are ones you will also have to make if you want to stay PEP 8 compliant (pycodestyle's E203 is invalid inside slices) and you want your code to execute on Python pre-3.6 (where you…

> where you can't add trailing commas to calls and signatures containing args and kwargs I think that's signature only. You don't have problems with calls: $ python3.5 Python 3.5.5 (default, May 17 2018, 07:04:26) [GCC 7.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> def foo(*args, **kwargs): ... print(*args, **kwargs) ... >>> foo( ... 'abc', ... ) abc >>> The argument black…

Yeah, call side was fixed in 3.5 but I don't split hairs here. I consider it either 3.6+ or don't put trailing commas after neither signatures nor calls with stars.

BTW, your signature doesn't demonstrate a call with unpacking. What you meant to test was:

l = [1, 2, 3] foo(0, *l,)

This works in 3.5+ but fails on 3.4 and before.

Post reply on HN