You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now it's clear where one block starts and another ends. At the moment I'm accomplishing this by running black as a first pass and then using parso to add newlines for each found block. The general rule of thumb I take take is
"if it's not the first source code line, it needs 1 newline before the block". So you won't end up with situations like
for_inrange(10):
ifTrue:
pass
The same logic applies to control flow statements. break, continue, return, and yield.
The break and return statements in this scenario have incorrect indents. break should be in the inner for loop and return should be outside of the with block. It's hard to tell that they're on incorrect indents because nothing separates the blocks.
Now that the statements are separated, it's clear that break shouldn't be where it is. And because the return line isn't competing with bar(), it's easier to read, too.
I'd love to see this be brought to black because it's been so helpful.
The text was updated successfully, but these errors were encountered:
These changes were already addressed in #1219 and #90. I would recommend reading up on them (TL:DR is below though). Quoting from ambv in #1219:
Black used to initially have a strong opinion about all blank lines. My initial thinking was that if you need to split your functions into sections... you want more functions. But this argument proved to be extremely unpopular so I backed out of it.
And ftruzzi, if you look at the history of the project, Black initially did put blank lines after control flow statements (return, raise, continue, and break). I like this myself but unfortunately there were annoying edge cases with it so it was not a good rule to enforce every time.
So in general, I think we won't be doing what this request is suggesting. There are related bugs (like handling double blank lines in functions that are preceeded by a comment line; or standardizing on no blank lines after docstrings) that we might address. But we sadly cannot enforce any blanket usage of blank lines.
TL:DR is that changes of this kind are a bit too controversial and would've hurt the adoption of Black, so it was decided to not enforce any form of usage of single empty lines within functions. It also wouldn't help that this feature would be have a few annoying edge cases. Therefore you as the user will have to add single empty lines after control flow statements.
When Python statements aren't split with whitespace, relevant details like "which block is this
else
meant for" get lost.There are 2
else
blocks, neither of which apply to the nearbyif
blocks. But you may not notice because of the layout.Compare that to:
Now it's clear where one block starts and another ends. At the moment I'm accomplishing this by running black as a first pass and then using parso to add newlines for each found block. The general rule of thumb I take take is
"if it's not the first source code line, it needs 1 newline before the block". So you won't end up with situations like
The same logic applies to control flow statements.
break
,continue
,return
, andyield
.Code like this is hard to decipher.
The
break
andreturn
statements in this scenario have incorrect indents.break
should be in the inner for loop andreturn
should be outside of thewith
block. It's hard to tell that they're on incorrect indents because nothing separates the blocks.Now that the statements are separated, it's clear that
break
shouldn't be where it is. And because the return line isn't competing withbar()
, it's easier to read, too.I'd love to see this be brought to black because it's been so helpful.
The text was updated successfully, but these errors were encountered: