If you write Python and don't know what PEP8 is go and check it now.

PEP8 is the style guide for Python code and I think is quite good and I very much encourage people to put a linter + static analyzer as first step before running tests in CI/CD systems as a smoke test and keep things kind of tidy (at the micro level, I'm not talking about architecture here).

But this guide line lacks in some places where it promote styles that are fragile and could be improved:

Fragile indentation

This is a style that is acceptable by PEP8, but it is fragile.

# Aligned with opening delimiter.
foo = long_function_name(var_one, var_two,
                         var_three, var_four=4)

Something is fragile when it breaks easily, and is quite easy to break this indentation by changing the name of foo or long_function_name and instantaneously this the parameters in the second line would be miss-aligned.

# Aligned with opening delimiter.
foo = refactoring(var_one, var_two,
                         var_three, var_four=4)

There are some editors that will correct this for you automatically but not everybody has those. Also sometimes I find abandoned code like this from someone who had to escape a building on fire or something.

And is not very pleasant when long function calls are together looking something like:

# Aligned with opening delimiter.
foo = long_function_name(var_one, var_two,
                         var_three, var_four=4)
barf = another_long_function_name(var_one, var_two,
                                  var_three, var_four=4)

Where the amount of spaces is irregular even when semantically both lines are at the same level. Is just visually misleading.

If we just listed the parameters of the function one per line with trailing commas:

# Aligned with opening delimiter.
foo = long_function_name(
    var_one, 
    var_two,
    var_three, 
    var_four=4,
)

In this case when you change the name of the function, remove or add parameters, or change the name of the parameters the rest of the indentation is not broken. If you add a new parameter or remove one, the diff for code review will show as a single line change per parameter modified:

 # Aligned with opening delimiter.
 foo = long_function_name(
     var_one, 
     var_two,
-    var_three, 
     var_four=4,
+    another_var=5,
 )

Very nice and easy to identify changes when you do side by side comparison.

Line continuation and breaks

In Python if a line is too long you can use \ to continue in the next line. In my personal taste this looks kind of ugly and you always need to keep in mind all those breaks in imports for example:

from django.db.models.expressions import Case, Exists, Expression, \
    ExpressionList, ExpressionWrapper, F, Func, OuterRef, RowRange, Subquery, \
    Value, ValueRange, When, Window, WindowFrame

If you have to delete or rename things there, the indentation length of the lines will look funny and you may have to wrap the whole text and re-arrange all the backslashes.

So why not to use parenthesis as a grouping mechanism, like in math:

from django.db.models.expressions import (
    Case, Exists, Expression, ExpressionList, ExpressionWrapper, F, Func,
    OuterRef, RowRange, Subquery, Value, ValueRange, When, Window, WindowFrame,
)

Or also:

from django.db.models.expressions import (
    Case, 
    Exists, 
    Expression, 
    ExpressionList, 
    ExpressionWrapper,  
    F, 
    Func,
    OuterRef, 
    RowRange, 
    Subquery, 
    Value, 
    ValueRange, 
    When, 
    Window, 
    WindowFrame,
)

I don't like this last one because is too long and usually imports don't change that often, but this last style is also acceptable and has all the advantages of the example 1 I showed above, is refactoring proof.

When calling something too long

posts = (
   Posts.objects
   .exclude(author=user)
   .filter(title__startswith='hellow')
   .first()
)

When having a long if:

if (not previous_is_grouped
        and not prev.has_two_images
        and nextone
        and not nextone.has_two_images):
    do_evil_stuff()

Here I don't like the break in continuation between the first line of the if and the rest but it's fine.

Also when doing long list comprehension:

double_of_evens = [
    x * 2
    for x in range(100)
    if x % 2 == 0
] 

The lines are for: mapping, iteration and filtering.

Closing

General style guidelines for a language and a whole community are amazing and I love it. But don't be blind, if you really think there is a real reason to do things a little bit better take that step.

Think about all the abandoned code of people that had to flee buildings in flames. LOL 😂.