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

111–120 of 256 posts

Re: Django: Reformatted code with Black

#111

Post by progval »

ziml77 wrote: post #64
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…

Try isort instead https://github.com/PyCQA/isort

isort also kind of has this bad behavior when using 'import as':

    $ cat foo.py 
    from x import a, b, d, e
    from x import c as C

    $ isort foo.py 
    Fixing /tmp/foo.py

    $ cat foo.py 
    from x import a, b
    from x import c as C
    from x import d, e

Re: Django: Reformatted code with Black

#112

Post by terr-dav »

tempay wrote: post #6
VWWHFSfQ wrote: post #2

So now when you look at the annotated change history all you're going to see is a bunch of changes by the person that reformatted the code instead of the person that wrote it.

The `.git-blame-ignore-revs` file can be used to ignore that (and will be [1]). Unfortunatly GitHub doesn't support it but at least it's possible to have clients behave in a reasonable way. [1] https://github.com/django/django/pull/15387#issuecomment-103...

You can automate setup for developers using this simple script:

https://github.com/ipython/ipython/pull/12091/files

And here’s a GitLab issue requesting support for blame-ignore:

https://gitlab.com/gitlab-org/gitlab/-/issues/31423

I don’t think there’s a corresponding GitHub request, but maybe if GitLab adds this feature GitHub will have some incentive to follow suit.

Re: Django: Reformatted code with Black

#113

Post by crad »

BiteCode_dev wrote: post #99
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 configurable, and that's why it never won.

What's wrong with configurable? Too much opportunity to bikeshed?

I figured yapf was not "new" which is why black won.

Starting about 5-6 years ago there was a push in the Python community to replace solved problems with new ones in what appears to me as chasing the JavaScript community.

Instead of consolidating on existing tools that worked well but had some rough edges to smooth out, numerous projects came about to reinvent the wheel.

Re: Django: Reformatted code with Black

#114

Post by mynegation »

OJFord wrote: post #87
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.

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.

Re: Django: Reformatted code with Black

#115

Post by BiteCode_dev »

crad wrote: post #113
BiteCode_dev wrote: post #99

Earlier quoted context omitted.

yapf is configurable, and that's why it never won.

What's wrong with configurable? Too much opportunity to bikeshed? I figured yapf was not "new" which is why black won. Starting about 5-6 years ago there was a push in the Python community to replace solved problems with new ones in what appears to me as chasing the JavaScript community. Instead of consolidating on existing tools that worked well but had some rough edges to smooth out, numerous projects came about to…

There is no "best format". It's a matter of opinion.

Taste is something we cannot objectively agree, and in fact, people will end up arguing even about this very statement, offering what they think is an objective measure.

Bikesheding, yes. Hours lost in meeting, chat debates, documentation to write, linting configuration. To be redone for each project, team, etc. Worse even in FOSS where everybody will come in a ticket and complain. And after while, you do it again, because the debate is never settle even in the same team or project.

There is not way to take a team of 3 people, choose a style, and make it so that they are all 100% happy with it.

Black took the road of gofmt: you can't chose. And it won because of that: it saved people time and energy.

People realize the cost was not worth the satisfaction, which you are unlikely to get anyway. Let's just move on to what matters, it's good enough. Pareto.

Re: Django: Reformatted code with Black

#116

Post by VWWHFSfQ »

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

Looks cool but it seems like it might still need some work?

I tried it on one of my Django `admin.py` files and it created NameErrors.

    class TestAdmin(admin.ModelAdmin):
      list_filter = ("foo_method",)

      def foo_method(self, obj):
        return "something"

      foo_method.short_description = "Foo method"

    # It turned it into this:

    class TestAdmin(admin.ModelAdmin):
      list_filter = ("foo_method",)

      # NameError
      foo_method.short_description = "Foo method"

      def foo_method(self, obj):
        return "something"

Re: Django: Reformatted code with Black

#117

Post by 3pt14159 »

Kinrany wrote: post #43
declnz wrote: post #13

Aside: I love a good linter, but as a long-time Python fan I find it sad that Black has so little configuration (yes, I know, but still) and moreover that it often produces code that no human Python dev I know would write... Python was always meant to look concise / beautiful... (MyPy has also made this trickier too)

People conflate opinionated formats with autoformatting for some reason. An autoformatter removes 99% effort from formatting code, and that includes code actively being worked on. Autoformatters are incredibly useful. A standardized format removes effort spent learning to read a new format. That's an hour per format at most. I don't see any good reasons for an autoformatter to enforce a standard. A standard would wor…

Well, sorta. It's really, really mentally annoying switching between projects where standards are different. For example 80 char limit to 120 char limit takes me at least a month to fully get used to. I agree black is better than the alternative, I agree it has downsides, I'm happy some of the parameters are tunable, but I'm also glad most of them are not. I just want to write software with tools I'm used to.

Re: Django: Reformatted code with Black

#118

Post by BeFlatXIII »

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

Thanks for sharing this. When solo coding, I tend to dump new classes and functions wherever is physically closest to where I was previously editing. It makes sense in the moment so I don't disrupt my train of thought by jumping all over the file, but then is a confusing ball of mud when I need to return to the project after time off. Was the shortest scroll direction up or down when I implemented it? etc…

Re: Django: Reformatted code with Black

#119

Post by MisterTea »

acdha wrote: post #82
MisterTea wrote: post #57

Earlier quoted context omitted.

> Working on a team where each engineer has their own personal syntax is not fun. Why did your team not implement a style guide? Not following style is not working as a team and this needs to be addressed.

Style guides are a notorious time-sink where people will spend enormous amounts of time debating various conventions without that being linked to measurable benefits. One of the big problems here is that people notoriously conflate “familiar” with “better” and you rarely run the counter-experiment showing that after a couple weeks everyone would be familiar with any of the serious proposals. The advantage of a tool l…

> Style guides are a notorious time-sink where people will spend enormous amounts of time debating various conventions without that being linked to measurable benefits.

It feels like we're trying to justify the continued employment of uncooperative, contrarian egoists. Pick a style and use it or they can go find another job to waste time debating nonsense.

Re: Django: Reformatted code with Black

#120

Post by BeFlatXIII »

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…

I have a bad habit of

from typing import *

because I get annoyed at having to change my imports each time I need a new type in my type annotations.

Post reply on HN