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

Django: Reformatted code with Black

github.com

Post reply on HN
Print view View original

161–170 of 256 posts

Re: Django: Reformatted code with Black

#161

Post by thiht »

steve_taylor wrote: post #157
mrtranscendence wrote: post #20

I've been using black at work for over a year now. I don't much care for some of the choices it makes, which can sometimes be quite ugly, but I've grown used to it and can (nearly) always anticipate how it will format code. One nice side effect of encouraging its use is how, at least where I work, it was very common to use the line continuation operator \ instead of encompassing an expression in parentheses. I always…

At least it doesn’t have a dishonest name such as Prettier, which turns perfectly good looking code into digital vomit.

Stop thinking opinions on code style are objective. Prettier is good enough and NOT « digital vomit ». Wtf.

Re: Django: Reformatted code with Black

#162

Post by lelandbatey »

codingkev wrote: post #90

A little shoutout to a alternative Python formating tool https://github.com/google/yapf (developed by Google). The built in "facebook style" formating felt by far the most natural to me with the out of the box settings and no extra config.

YAPF is slower than Black for many degenerate cases, a fact I notice most strongly since I use an "auto-format file on file save" extension in my editor. The case I found in particular was editing large JSON schema definitions in Python, as they're represented as deeply nested dictionaries. Black seems to format them in linear time based on the number of bytes in the file, while YAPF seems to get exponentially slower based on the complexity of the hard-coded data structure. It was a niche case, and the maximum slowdown was only ~1-2 seconds, but that editing freeze was quite annoying.

Re: Django: Reformatted code with Black

#163

Post by michaelbarton »

VBprogrammer wrote: post #153

Reading some of the comments here it's become clear to me that the next stage in the development of auto-formatters is to have the formatter commit the code as a canonical format but to display the code to each individual contributor in the style of their choosing. Thus removing all kinds of arguments about whether 80 or 120 columns is the one true width.

I think that’s already possible using git smudge.

Example here: https://bignerdranch.com/blog/git-smudge-and-clean-filters-m...

Re: Django: Reformatted code with Black

#164

Post by adamrt »

mynegation wrote: post #114
OJFord wrote: post #87

Earlier quoted context omitted.

Does the user matter? As long as the commit message is something sensible like 'Autoformat with black' it can be easily ignored when seen, and you can avoid seeing it with blame as simonw suggests.

The problem is that this revision will override all the previous ones in the “blame” output so it needs to be explicitly ignored. See a great link elsewhere in the thread on how to deal with that in newer versions of git.

Git blame has a feature just for this `git blame -w -M`. -w ignores white space changes and -M isn't really necessary but will ignore moved lines

Re: Django: Reformatted code with Black

#165

Post by [deleted] »

steve_taylor wrote: post #157
mrtranscendence wrote: post #20

I've been using black at work for over a year now. I don't much care for some of the choices it makes, which can sometimes be quite ugly, but I've grown used to it and can (nearly) always anticipate how it will format code. One nice side effect of encouraging its use is how, at least where I work, it was very common to use the line continuation operator \ instead of encompassing an expression in parentheses. I always…

At least it doesn’t have a dishonest name such as Prettier, which turns perfectly good looking code into digital vomit.

[deleted]

Re: Django: Reformatted code with Black

#166

Post by wyuenho »

simonw wrote: post #36
wyuenho wrote: post #23

Every time I was tempted to do something like this, I hesitated because I didn't want every other line in every file with my name on a single commit, mostly to avoid making git blame harder than necessary. It would be nice if there was a kind of diffing algorithm that can diff code units *syntactically* across history.

You can tell "git blame" to ignore specific commits which helps a lot here: https://www.moxio.com/blog/43/ignoring-bulk-change-commits-w...

The problem with this approach is, the blame before and after the ignored wouldn’t make any sense to the viewer if he didn’t know about ignoring the formatting commit. Also, you will need to configure that for every clone. Since tree diffing algorithms are pretty well known these days, I don’t know why there hasn’t been any real effort to implement a git plugin that can chase syntax tree node changes instead of doing string diffing like it was the 70s. Syntax parsers are so easy write now and surely the tree node changes can be cached. Your usual diff/patch tooling wouldn’t work for this kind of diff, but that’s just an option away when you need them back.

Re: Django: Reformatted code with Black

#167

Post by jessaustin »

barbazoo wrote: post #160
jessaustin wrote: post #156

Earlier quoted context omitted.

Who is using 120 chars?!?!? I can certainly understand the adjustment difficulties...

Are 120 chars bad?

Maybe it's because I only have one eye and the resulting slightly reduced width of field, but wide lines drive me crazy. I need to see the whole line without scanning. This was one of python's original appeals to me...

https://pep8.org/#maximum-line-length

Re: Django: Reformatted code with Black

#168

Post by mulmen »

VBprogrammer wrote: post #153

Reading some of the comments here it's become clear to me that the next stage in the development of auto-formatters is to have the formatter commit the code as a canonical format but to display the code to each individual contributor in the style of their choosing. Thus removing all kinds of arguments about whether 80 or 120 columns is the one true width.

You're absolutely right of course.

But even now I have to adapt on screen shares when my coworkers are using dark themes before sunset. Can't imagine what that would be like with different code formatting. So the next next step is to display their desktop with my theme.

IOW collaboration tools still have a long way to go.

Re: Django: Reformatted code with Black

#170

Post by bwhmather »

progval wrote: post #105
bwhmather wrote: post #84

Shameless plug: For people who like black, I've been working on ssort[0], a python source code sorter that will organize python statements into topological order based on their dependencies. It aims to resolve a similar source of bikeshedding and back and forth commits. 0: https://github.com/bwhmather/ssort

Could you show an example in the README? The first two pairs of input/output in https://github.com/bwhmather/ssort/tree/master/examples look unchanged

Will do. Examples directory isn't terribly helpful as documentation as it mostly contains real code with problematic syntax (and compatible licensing) that tripped up ssort when I ran it on a copy of my pip cache. I will move it into tests to avoid confusion
Post reply on HN