Opinions: do not remove logical block new line inside of functions

[Sapphire64]

Just ran black on one of the repos I have. While many things are fine or OK, I have several business logic files where only new lines were removed between logical blocks inside of functions.

Even by looking at black's own codebase it would benefit from newline separation inside of some functions, like this one: https://github.com/ambv/black/blob/master/black.py#L1188

Wall of text is not making something more readable, especially for people with sight disabilities. But maybe I'm missing some trend in Python community, so would like to hear others' opinions on this.

[njsmith]

I've been comparing black to yapf on a project. I love the philosophy and simplicity of black compared to yapf. But aside from minor bugs that I'm sure will be fixed soon, black's insistence on screwing around with adding and removing newlines is probably the biggest difference between them, and I kind of hate it.

[linusg]

@Sapphire64 I agree on this. I love the simplicity but it just made my code almost unreadable at some points because it removed a bunch of newlines forming logical blocks.

[ambv]

I agree it is aggressive and probably too aggressive. Empty lines outside of parenthesized expressions should probably be left alone.

As a rule of thumb though, creating "sections" inside functions generally signifies you want more functions. If you can't (or are unwilling to) split them, creating standalone comments that signify what the next "section" is supposed to do is a workaround I can offer for now, until I address this more holistically in a future release. It's doable but probably not this week.

[linusg]

Fair point, which I should probably take under consideration far more often 😉

But obviously sometimes it's just not practical, e.g. when declaring some variables and then starting an if, for, while, with etc. I usually prefer a blank line there.

Nevertheless, thanks for your great work!

[Sapphire64]

@ambv this is why I was asking others opinions on this, because yes, in some cases it's just a sign that function should be divided into multiple.

But not always, example which lead me to create this ticket was about vars definition inside of the function, which I was filling in later and give back as the output. Just now had another example: 6 lines of code function which calls 6 other functions in a chain, and a new line separation was a great thing to have in between two parts of it :) abstraction was quite deep already, because it's obvious that I was struggling to name that aggregation function.

Regarding comments - I'm just realising that I'm not writing that much comments, except not-that-nice places in code where you have to almost apology :) I prefer to have code itself as readable as a sci-fi book (well, I'm trying! :D) and considering both examples I've provided the comment would bring 0 value (if not harm) to potential reader.

But I'm glad that you're going to look into this. Thanks for your work!