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

231–240 of 256 posts

Re: Django: Reformatted code with Black

#231

Post by throwaway9870 »

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…

I am just about to embark on resolving differences in our code base due to two different clang format files being used by different teams that have now merged. Can't wait to have all those conversations and discussion over which options are correct.

One hour my ass.

Re: Django: Reformatted code with Black

#232

Post by throwaway9870 »

njharman wrote: post #181
Kinrany wrote: post #43

Earlier quoted context omitted.

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…

In 30yrs of dev the truest statement in standards I can make is that they change, all the time. The 2nd truest is I and coworkers have wasted far to much energy on arguing and maintaing STDs. Blacks value isn't autoformatter, it's preemptive discussion ender.

> Blacks value isn't autoformatter, it's preemptive discussion ender.

Exactly. I have learned that having it formatted just like I want it is FAR FAR FAR less important than having the entire ecosystem share a single format.

Re: Django: Reformatted code with Black

#233

Post by squeaky-clean »

zem wrote: post #218
eternauta3k wrote: post #177

Earlier quoted context omitted.

Indentation is not the reason why it's hard to autoformat Python code, or any other language for that matter.

it's definitely a reason for python. consider: if foo: if bar: do something else: do something else how would you autoindent that?

You wouldn't, as that's not a valid python line.

Re: Django: Reformatted code with Black

#234

Post by frosted-flakes »

spc476 wrote: post #222
belval wrote: post #53

Earlier quoted context omitted.

I disagree on that though. By sticking to vanilla Black (no pun intended) you ensure that people joining your time will probably already be familiar with the style, you prevent strongly opinionated employees from pushing for changes in the linter config. Black is opinionated, so it skips the debate entirely. We just use Black, not black with 120 characters lines, just Black. To each their own I guess, but to me it ju…

Yes, it's opinionated, but who's opinion got carved into stone?

Does it matter?

Re: Django: Reformatted code with Black

#235

Post by aij »

bwhmather wrote: post #201
mkesper wrote: post #188

Earlier quoted context omitted.

But this is really backwards? Everyone uses the if __name__ == "__main__" dance to avoid calling functions before they're defined, no?

It is a bit backwards, but in exchange you get predictability With backwards sorting you know that, unless there is a cycle, you can always scroll up from a call site to find the definition or down from a definition to see where it is used. With forwards sorting you can scroll down to find a definition, unless the function was imported, or used as a decorator somewhere, or called by something that was used as a decor…

I never thought of it as backwards. Defining functions before calling them makes as much sense as defining terms before using them or assigning variables before reading them.

Re: Django: Reformatted code with Black

#236

Post by yurishimo »

wraptile wrote: post #230
TheRealPomax wrote: post #204

The reason to use Black is the same as Prettier on the HTML/CSS/JS side: forever stop having an opinion on code style, it's wasted time and effort. Any "it's not exactly what we want" comment with an attempt to customize the style to be closer to "what we were already using" is exactly why these things exist: by all means have that opinion, but that's exactly the kind of opinion you shouldn't ever even need to have,…

Except Python is a general purpose programming language so it's hard to have 1 shoe fits all solution when style vary based on medium you're working with. Are you making an OOP GUI app? Django? Something that is using loads of long Xpaths?

I don't know if that applies. Ideally, a good code formatting tool would work with any project. If there is a specific flag you want to disable for some block to use your own format, then the tool should support that.

As a couple of examples, PHP has had a unified formatting standard since 2013 and Elixir has a formatter built into the language. Both languages need the formatter to be enabled by your IDE/CI and that's also the case for Black.

Re: Django: Reformatted code with Black

#237

Post by pyuser583 »

wraptile wrote: post #230
TheRealPomax wrote: post #204

The reason to use Black is the same as Prettier on the HTML/CSS/JS side: forever stop having an opinion on code style, it's wasted time and effort. Any "it's not exactly what we want" comment with an attempt to customize the style to be closer to "what we were already using" is exactly why these things exist: by all means have that opinion, but that's exactly the kind of opinion you shouldn't ever even need to have,…

Except Python is a general purpose programming language so it's hard to have 1 shoe fits all solution when style vary based on medium you're working with. Are you making an OOP GUI app? Django? Something that is using loads of long Xpaths?

Python throws exceptions if you don’t have the right number of indents.

Re: Django: Reformatted code with Black

#238

Post by shpx »

spc476 wrote: post #223
glacials wrote: post #16

Black is slowly creeping into gofmt-level universality in the Python community and it’s great. The next big milestone is a first-party recommendation by python.org itself.

No, the next big milestone is embedding the format style as the syntax of the language. I'm curious as to why Go didn't even do this (they should have, in my opinion, but wimped out and left it to an external tool).

If they change

    print(repr('some string'))
to print

    "some string"
instead of

    'some string'
then that would remove the only hangup about Black that I have.

Re: Django: Reformatted code with Black

#239

Post by wyuenho »

nickysielicki wrote: post #220
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.

The best way to do this is to rewrite history with git filter branch / etc and rerun black at every commit. Then everyone nukes their clone and you continue on with the best of both worlds. The only real downside is you nuke your issue tracker at the same time.

That’s correct. Which is a shame.

Re: Django: Reformatted code with Black

#240

Post by bredren »

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.

This is the way. I had not considered this before reading your comment.

If this system results in syntactically identical code [1] it should not matter if it’s displaying for you differently [2] if it means you can read or write around or in it more comfortably it’s just a hairstyle.

I was asked to familiarize myself with Replit the other day and it seemed the editor defaulted to two spaces for Python. Two spaces?! I changed it to four.

A friend joined my session and began to code with me, their editor was in the default two space indentation. It was madness.

[1] This seems like is a decent sized presumption across many languages and versions.

[2] This seems like an interesting AI problem, showing code structures you’ve never used in your style you’ve never defined.

Post reply on HN