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

Black – Uncompromising Python code formatter

github.com

Post reply on HN
Print view View original

201–210 of 251 posts

Re: Black – Uncompromising Python code formatter

#201

Post by crehn »

john-radio wrote: post #117

I like black. As hprotagonist pointed out, everyone has a few things about it they don't like. What I like to do: $ black --skip-string-normalization my_python_script.py $ git add --patch my_python_script.py Then I accept or reject all its suggestions (other than the string "normalization" idea which is not our convention) on a case-by-case basis, then `git commit; git reset HEAD --hard`.

Seems like a lot of work just to satisfy some arbitrary aesthetic sensitivity.

Especially when working in teams, I couldn't care less about the style itself. As long as it's consistent, super easy to adhere (`black .`) and fairly readable, I'm happy.

Re: Black – Uncompromising Python code formatter

#204

Post by globuous »

cjbprime wrote: post #35

I often dislike autoformatter output too, but then I remember that while no-one likes what the autoformatter does to their code, everyone likes what the autoformatter does to their coworkers' code, and then I chill out about it. Having a standard is more important than the standard being excellent.

That and it also saves our fingers' lives. Seriously, formatting code "by hand" just hurts. I highestly recommend anyone concerned about developing rsi to start autoformatting their code.

Re: Black – Uncompromising Python code formatter

#205

Post by globuous »

strangemonad wrote: post #65
p0cc wrote: post #5

I use black because it is idempotent. Google's yapf lacks this property. Edit: Previous discussion: https://news.ycombinator.com/item?id=17155048

Unrelated: thank you for using “idempotent” correctly. Too many people use it to mean referential transparency or having a functionality property

wooow, so can we think of Black as outputing a projection of your source code in some space ?

Re: Black – Uncompromising Python code formatter

#206

Post by acdha »

tedmiston wrote: post #59
rav wrote: post #43

Earlier quoted context omitted.

I completely agree that black does not format all examples in a nice manner, and your example is something I see pretty often. Whenever black adds too many indentation levels and line breaks in what should be a simple-enough statement, I simply refactor into multiple statements, e.g. stems = { apple.stem for satchel in satchels for apple in satchel } basket.add(stems) I concede that without black it wouldn't have mad…

It's an interesting meta thought that using the autoformatter changes the way you write your code. Not that that's implicitly a good or a bad thing, I just find it interesting.

I think it’s under-appreciated when comparing tools like this. I’ve noticed that a bit since adopting Prettier and Black and one thing I’ve noticed during code review is that usually when I end up changing code structure to get better results from the tool, it’s a refactor that I probably would felt like I should have done but might have put off due to laziness even though it’s really not that much work.

I’m kind of thinking of it as something like baking some exercise into your day by putting a walk into your commute: the little nudge of not fighting the tool on something minor means you don’t skip little things, and over time that adds up more than it seems at first.

Re: Black – Uncompromising Python code formatter

#207

Post by thaumasiotes »

owenmarshall wrote: post #128
cjbprime wrote: post #35

I often dislike autoformatter output too, but then I remember that while no-one likes what the autoformatter does to their code, everyone likes what the autoformatter does to their coworkers' code, and then I chill out about it. Having a standard is more important than the standard being excellent.

> no-one likes what the autoformatter does to their code, everyone likes what the autoformatter does to their coworkers' code It always strikes me as strange that we spend our own effort and time on systems that mandate code style when my unambiguously correct style and my coworkers obviously incorrect style both end up converted to the same AST for any useful work. Why isn't style an entirely local choice, with a hi…

> What wheel did I point towards and suggest be reinvented?

Pretty printing.

Re: Black – Uncompromising Python code formatter

#209

Post by weberc2 »

mychael wrote: post #107

Having worked in Python for many years, I can tell you that nobody actually writes code that looks like Blacks formatting. It's a major step backward for the Python community.

Having worked in Python and other languages for many years, I can tell you that 1) this doesn't matter and 2) many of the ways people write Python are much uglier than the conventional formatting in other languages. Most notably:

    this_is_my_very_long_function_name_and_here_come_the_args(self,
                                                              foo,
                                                              bar,
                                                              baz)

Re: Black – Uncompromising Python code formatter

#210

Post by thaumasiotes »

globuous wrote: post #205
strangemonad wrote: post #65

Earlier quoted context omitted.

Unrelated: thank you for using “idempotent” correctly. Too many people use it to mean referential transparency or having a functionality property

wooow, so can we think of Black as outputing a projection of your source code in some space ?

Off the top of my head, sure, you could think of things that way, but I don't see that you get a lot out of that framing.
Post reply on HN