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

31–40 of 256 posts

Re: Django: Reformatted code with Black

#31

Post by Joeboy »

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…

    from typing import (
        overload,
        List,
        etc...,
    )
would seem more sensible to me. I know you can make isort do that, I guess maybe not black.

Re: Django: Reformatted code with Black

#32

Post by heavenlyblue »

declnz wrote: post #28
belval wrote: post #22

Earlier quoted context omitted.

Indeed, I don't like Black's style, but I prefer working in a Black codebase than one where everyone has their own preference. Having style guidelines in a team is also a great way to remove pointless debates when reviewing PRs.

+1 ...which is why I wish Black allowed more configuration. A team can often agree on a set of styles. Every team on the Python planet agreeing... now that's much harder

> A team can often agree on a set of styles.

What for? Just to be clear even Django itself isn't obviously using a configuration, what makes your team so special they need this?

Re: Django: Reformatted code with Black

#33

Post by simonw »

justinmchase wrote: post #3

The output does look better but this also just looks like every PR for applying a linter / formatter I've ever seen. Not sure why this is news worthy.

It's a significant milestone in the adoption of Black by influential projects within the Python ecosystem, which makes it a good hook for discussing the idea that Black, now stable, is becoming established as the standard for code formatting for Python.

Re: Django: Reformatted code with Black

#34

Post by wodenokoto »

tomp wrote: post #27

worst things about Black: - doesn't respect vertical space - sure, making the code fit on screen might be valuable (though the default width should be at least 120 characters, I mean we're in 2022 after all), but Black does it by blowing up the vertical space used by the code - spurious changes in commits - if you happen to indent a block, Black will cause lines to break - Black fails at its most basic premise - "avo…

> - Black fails at its most basic premise - "avoiding manual code formatting" - because a trailing comma causes a list/function call to be split over lines regardless of width

Yeah, this one drives me nuts too.

Re: Django: Reformatted code with Black

#35

Post by sciurus »

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

For anyone looking for more explanation of this feature:

https://michaelheap.com/git-ignore-rev/

Re: Django: Reformatted code with Black

#36

Post by simonw »

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

Re: Django: Reformatted code with Black

#37

Post by sciurus »

ibejoeb wrote: post #25

In general, what are the strategies for large public codebases like this to mitigate supply chain attacks or other source-level attacks? For clarity, I'm hoping to open us discussion about how we're dealing with massive changesets like this that are difficult to review due chiefly to the breadth of it.

For a purely mechanical change like this, someone could run black against the same revision of Django and verify the changes they see locally match the changes in this PR.

Re: Django: Reformatted code with Black

#38

Post by declnz »

heavenlyblue wrote: post #30
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…

Why do you even care? I never look at that part of the code. If PyCharm automatically removed/added imports without me managing them I would be a happier person.

But Pycharm can (pretty much)!

Alt-enter over the would-be imported term to add an import, ctrl-alt-O to autoformat / autoremove (aka optimise) redundant ones.

You can then turn on folding to not see those imports much via Prefs -> Editor -> General -> Code Folding

Re: Django: Reformatted code with Black

#40

Post by jeffshek »

heavenlyblue wrote: post #30
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…

Why do you even care? I never look at that part of the code. If PyCharm automatically removed/added imports without me managing them I would be a happier person.

There is an option to hide and autoformat inports.
Post reply on HN