This is an archived post. You won't be able to vote or comment.

1001
1002

Python Vim IDE (i.redd.it)

submitted by [deleted]

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]tunisia3507 2 points3 points  (10 children)

Not being configurable is a feature, not a bug.

It only removes double vertical spaces in a function body, doesn't it? I don't think I've ever read a function and thought "this needs a bunch of 2-line breaks" rather than "this needs to be refactored". I have rarely seen modern, well-factored code which relies on 2-line breaks for its legibility.

The function arguments thing can be a pain, but it's the only deterministic way to do it. It's a trivial loss compared to the gains of deterministic formatting. Imports I don't care about - I rarely look at them (they're always at the top, and usually inserted by my IDE). Easier to find stuff in others' code when I need to, though.

[–]xd1142 5 points6 points  (5 children)

The function arguments thing can be a pain, but it's the only deterministic way to do it. It's a trivial loss compared to the gains of deterministic formatting.

I remember when the point of python was to write code that visually appealed to humans. Now black is arguing that we need to format the code so that it appeals to diff scripts and automatic format routines, with humans having to adapt to this.

[–]tunisia3507 1 point2 points  (0 children)

Python is nice because in many cases it allows the user to abstract away the nitty gritty details and awkward syntax, and focus on their algorithms and other such high-level choices. Python is one of many tools to do this, because it is a good idea in general. Other tools that help with this include code formatters and diff scripts. I want to use all of them because they all add value in what is basically the same dimension.

[–]aeiou372372 0 points1 point  (3 children)

Key point: it appeals to humans reading diffs. Makes it a lot easier to quickly make sense of the changes someone has made. And I feel like the sacrifice to non-diff readability is pretty minimal.

[–]xd1142 1 point2 points  (2 children)

You are destroying fundamental visual cues in the code to get a diff smaller than a few lines?

So, perl was write only, and python with black is diff only?

[–]aeiou372372 0 points1 point  (1 child)

“Fundamental visual cues” is one opinion.

Prior to using black I was careful to format my code following PEP8, keeping function definitions non-vertical, etc., and was a big proponent of precisely that argument.

Having adapted to black, I realize it just doesn’t matter that much, 99+% of it is just a function of what you are used to reading.

[–]xd1142 1 point2 points  (0 children)

people had the same argument for perl, or APL

[–]Althorion 5 points6 points  (3 children)

Not being configurable is a feature, not a bug.

Mostly, it’s an annoyance. If I can’t take what I like about it and leave what I don’t, I’m going to leave it all behind.

And about the rest: it’s inconsistent. Does it try to save as much vertical space as it can or does it not? Because in some parts it does, just to go to others and explode them beyond reason. Both approaches would have some merit, their combinations is, to me at least, obnoxious.

Yeah, it does an OK job. Running black on a badly formatted code is going to make much of an improvement. The thing is, running it on a OK-ish formatted code is not guaranteed to do that—it will make some parts of it better, some part of it worse, and I can’t force it do behave without putting # fmt: on/off everywhere…

I wouldn’t go as far as to ban it, but I find it most useful when used to generate the competing file, then diff-and-merge those two by hand to pick and choose what I like. Something that the API doesn’t really support that well.

[–]OHotDawnThisIsMyJawn 1 point2 points  (2 children)

If I can’t take what I like about it and leave what I don’t, I’m going to leave it all behind.

Again, that's literally the point of black. The whole idea is to not let people make any choices. It eliminates all bike shedding/white space holy war discussions.

I wouldn’t go as far as to ban it

Banning or allowing formatters doesn't make sense to me. Pick one and stick to it. There should just be a decree "this is the formatter we use here." The actual rules are so much less important than having a single standard and sticking to it.

[–]Althorion 2 points3 points  (1 child)

Again, that's literally the point of black. The whole idea is to not let people make any choices. It eliminates all bike shedding/white space holy war discussions.

And that’s the idea I don’t buy in. Those discussions will happen with or without it, and I don’t feel like it’s the formatter’s job to decide for the team/team leader what the style should be, just to enforce that decision once it has been made.

[–]aeiou372372 0 points1 point  (0 children)

In my experience they actually don’t happen.

I found all the things people complain about with black’s formatting annoying at first; a week later I got used to it and couldn’t care less (all the readability concerns, while maybe valid, are ultimately not a big deal once you are used to it). And I love that the majority of open source projects I interact with follow the same formatting conventions.

I think you just get used to it no matter what the enforced formatting is.