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

101–110 of 256 posts

Re: Django: Reformatted code with Black

#101

Post by terr-dav »

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

Here’s a script that automates the once-per-repository local setup of this feature:

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

Unfortunately there isn’t support for it in GitHub or GitLab yet, but there’s at least a GitLab issue here requesting it:

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

Re: Django: Reformatted code with Black

#102

Post by rurp »

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.

Not everyone uses PyCharm, but if you do it's really easy to highlight a specific code block and look through the git commit history for that section. I've used it many times for this exact type of problem, trying to find when the last substantive change happened.

To do this just highlight the block, right click, and choose Git > Show History for Selection.

Re: Django: Reformatted code with Black

#103

Post by dopeboy »

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

Very cool - I'll be following this.

Re: Django: Reformatted code with Black

#104

Post by kaesar14 »

NegativeLatency wrote: post #61
kaesar14 wrote: post #51

Earlier quoted context omitted.

Go and gofmt definitely pushed a lot of the momentum of the current wave but don't forget to give respect to Ruby / Rubocop where it's due, where the adage of Convention over Configurability has reigned supreme for decades.

Rubocop has about a thousand config options

Sure but the style guide standards exist and it's pretty rare for a Ruby application to stray from them (from my experience at a multi-billion dollar public company Ruby shop)

Re: Django: Reformatted code with Black

#105

Post by progval »

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

Re: Django: Reformatted code with Black

#106

Post by drcongo »

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

This is relevant to my interests. We have an internal code style guide at my company that includes guidelines for order of class statements, roughly matching yours. I have one pet peeve that made me write the style guide in the first place - Django's `class Meta` which we always have at the top of the class because it contains vital information you need to know as a programmer, like whether this class is abstract or not. Whenever I have to work with an external Django codebase and find myself scrolling through enormous classes trying to find the meta my blood pressure rises.

Re: Django: Reformatted code with Black

#107

Post by crad »

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)

I'll take yapf --style=pep8 formatting over black any day.

Re: Django: Reformatted code with Black

#108

Post by crad »

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…

yeah, it's just too bad that black violates PEP-8.

Re: Django: Reformatted code with Black

#109

Post by drcongo »

stjohnswarts wrote: post #94
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

This sounds like a living hell if you use git diff a lot to compare for small changes that might introduce a bug? which is what happens at work all the time since our unit test and CI are a joke. Not dumping on your project but the idea of that much of a change up of the code scares the dickens out of me.

Use it at the editor level instead of in CI and I can't see how it can cause you any problems at all. I could easily be missing something though?

Re: Django: Reformatted code with Black

#110

Post by luhn »

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

It also has a built-in "black" profile, so it only takes one line of config to get it to play nicely with Black.

https://pycqa.github.io/isort/docs/configuration/black_compa...

Post reply on HN