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

Black: An uncompromising Python code formatter

github.com

Post reply on HN
Print view View original

251–260 of 262 posts

Re: Black: An uncompromising Python code formatter

#251

Post by uryga »

zestyping wrote: post #190
uryga wrote: post #189

Earlier quoted context omitted.

> Black would sometimes change its mind about its own formatting and a second pass would cause a different formatting than the first Why not? I mean, I never built a formatter so idk about the complexity involved, but to me it seems that if Black had a rule like "if you see `a+b` (no spaces), just leave it alone", applying the rule twice shouldn't change anything. (though I imagine that the interactions of such rules…

The whole idea is to _prevent_ people from thinking about formatting, by actually making it impossible to make any formatting decisions. There's exactly one way to format the program and that's it. It's draconian, but that's what's great about it.

That's the feeling I got from the readme, but GP sounds like this particular decision was made not so much for 'philosophical' reasons, as because Black-ing a file twice might give different results. I was curious why :)

Re: Black: An uncompromising Python code formatter

#252

Post by joshuamorton »

zephyrfalcon wrote: post #213
ben509 wrote: post #161

Earlier quoted context omitted.

> I can understand the argument for having all code in the same format, but this kind of mechanism just seriously decreased my productivity, not in the least because it constantly pissed me off. Globally, though, code is read an order of magnitude more times than it's written. So it's a huge productivity improvement in the not particularly long run.

That doesn't really apply here... Like I said, Python code is already much more uniform than most other programming languages. Unless somebody's formatting style is particularly ridiculous, their code should be just as readable as anybody else's, even if they put a space where it supposedly doesn't belong, or use too many/too few blank lines, or use the "wrong" way to split and indent a long list of function paramete…

As someone who reads and writes a lot of python a, consistent style is incredibly valuable.

The only reason I don't use autoformatters is because most of them are bad. In my experience, black doesn't have those issues.

Re: Black: An uncompromising Python code formatter

#253

Post by asah »

ben509 wrote: post #160
ambivalence wrote: post #31

Earlier quoted context omitted.

Yeah, I wasn't willing to die on that hill, especially that I'm introducing a new default value that wasn't popular before.

It was a good call. Some code bases use long identifiers and an 80 column limit gets to be a mess. And for the 80 column fetishists, you'd have to pry their VT-100 terminals from their cold, dead hands. Disposing of the body is enough of a pain, but worse, you have to find a recycler who can deal with the lead glass in the CRT.

The modern argument for lower-line-lengths is the ability for more screens+fonts+UIs to display two blocks of code side-by-side. Somewhere between 80 and 120, you start to force many UIs to wrap. Adding to the subjectivity, approx nobody cares about one line of long code out of 100,000 -- so what percent of code-that-wraps is too much?

To avoid dying on that hill, many eng leads just throw up their hands and give into the 80-column folks, even if it's less productive for everybody else.

The beauty of gofmt and black is that formatting can become a commit hook, so no human wastes time cutting lines manually like some early 20th century typesetter.

Re: Black: An uncompromising Python code formatter

#254

Post by sametmax »

biztos wrote: post #158
ljm wrote: post #106

In case of credit where credit’s due, is gofmt where the concept of auto-formatting syntax became mainstream? At first I hated it because I thought I had a style, but later on I enjoyed the consistency far more than I enjoyed my signature approach. A programming language has an opinion on how you build software with it, so it’s appreciated that it also has an opinion on how you should write it so that it remains cons…

In the Perl world auto-formatting syntax is old hat, though of course (it being Perl) the formatter is highly configurable[0]. So in practice you get consistency within an organization, but perhaps not over time. Coming from that background I was initially put off by the lack of options with gofmt, but once I realized the whole world of go coders would be using the same formatting I immediately fell in love with it.…

Configurability for this means:

- debate

- time to setup the tool to your liking

- testing (and adapting to the style)

- and going back to 1 from time to time

So at best it's going to be costly, morally draining and repeated regularly, especially if you change team or in open source. At worst, which is the case for perl, it will not be used by most devs.

Re: Black: An uncompromising Python code formatter

#255

Post by sametmax »

pomber wrote: post #79

Is it possible to bind blackcellmagic[1] to run automatically everytime a cell is ran in a Jupyter notebook? [1] https://github.com/csurfer/blackcellmagic

You can explore putting something like :

    require([
      "base/js/namespace",
      "base/js/events"
    ], 
      function(Jupyter, events){
 
        events.on('finished_execute.CodeCell', function(){
          // execute black here
        });
    });
In ~/.jupyter/custom/custom.js.

Re: Black: An uncompromising Python code formatter

#256

Post by Too »

zachsnow wrote: post #237
Too wrote: post #216

Earlier quoted context omitted.

Why would you have strings that are not supposed to be human readable? Machine to machine should ideally use bytearray (b""-strings) or integer enums for that purpose. Then you also have the ambiguity of what is considered human readable, is an xml document human readable? Http headers? File paths? Urls? Is a programmer considered human?

I believe the point is whether the string is intended to be displayed to a human, not whether a human might read it in the code. Still some wiggle room around logging, etc. I guess.

Sorry if i wasn't clear, what i meant was actually why would you have strings that are not intended to be displayed to end user?

Smells like non binary serialization format or something alike, which is usually a code smell. It's convenient the first 2 weeks but once the project grows you need a more strict schema and once you have that you might as well use a serialization library which might as well have a binary serialization backend.

Re: Black: An uncompromising Python code formatter

#257

Post by aldanor »

weberc2 wrote: post #193
zestyping wrote: post #188

Earlier quoted context omitted.

I thought of another way to express this that might resonate better. What I like about the Black philosophy is that it wants to make code style _uninteresting_. People should think about other things, not formatting. That's a great goal. So it seems to me that the best style choice is the most _boring_ choice. The least creative, least novel way. It should try to avoid inventing new formatting algorithms. What's the…

I’m a Python programmer and I never had the perception that single quotes are more canonical in any capacity. I always felt that single quotes were for degenerates who didn’t realize that single quotes are most commonly used for chars by the broader programming community. ;)

You don't have to press Shift as often to type string literals so it's a win, all other things being equal.

Re: Black: An uncompromising Python code formatter

#258

Post by aldanor »

Too wrote: post #256
zachsnow wrote: post #237

Earlier quoted context omitted.

I believe the point is whether the string is intended to be displayed to a human, not whether a human might read it in the code. Still some wiggle room around logging, etc. I guess.

Sorry if i wasn't clear, what i meant was actually why would you have strings that are not intended to be displayed to end user? Smells like non binary serialization format or something alike, which is usually a code smell. It's convenient the first 2 weeks but once the project grows you need a more strict schema and once you have that you might as well use a serialization library which might as well have a binary se…

> why would you have strings that are not intended to be displayed to end user

Why would you not? E.g., you use pandas and columns all have names. Colors are typically also strings, etc. Thus you would often do things like

    grouped = df.groupby(['foo', 'bar'])['baz'].mean()
However, the parent's point, IIUC, is that he'd do

    grouped.plot(color='red', title="User-facing title.")

Re: Black: An uncompromising Python code formatter

#259

Post by aldanor »

ambivalence wrote: post #244
jhall1468 wrote: post #235

Earlier quoted context omitted.

The overwhelming response here saying use single quotes begs to differ.

That's not how this works. All the people who are just happy or indifferent about double quotes don't comment about it. And some of the ones that aren't happy about it commented here multiple times. Judging from the additional stars on GitHub, and projects that just migrated (pytest!), I'd say there's a very vocal minority which is very attached to single quotes.

This is all subjective unless some data is collected. I could say with just as much confidence that all of the major Python projects I've seen or contributed to use single quotes -- e.g. numpy or pandas.
Post reply on HN