One thing I find that makes a big difference is using the PEP8 indentation rules for writing lines of the form

    variable = some_function((some nested expression that is very long
                              and needs to wrap))

as

    variable = some_function((
        some nested expression that is very long but may not need to wrap
        but if it does there's tons more room for it))

I.e. you don't have to differentiate between 'syntax indents' and 'expression indents', every thing is just an indent of the same size. Which has the advantage that almost every editor can indent it correctly, and it works with both space and tab indents, whereas you're at the mercy of your Python editing mode whether the 'indent to sibling' works for everyone (and if not, the programmer has to sit tapping space to line it up right). Both approaches are in PEP8, but i find that simple change removes 99% of all >80 line cases for me.

The only caveat, also covered in PEP 8 is for function definitions.

    def some_descriptive_function_name(one_parameter,
                                       another_parameter):
        some_functionality()

becomes

    def some_descriptive_function_name(
            one_parameter, another_parameter):
        some_functionality()

i.e. the parameter lines are double indented.

Double indentation looks rather ugly though. I like the "K&R" style much better (as shown in comment from bpicolo):

    def some_descriptive_function_name(
        one_parameter,
        another_parameter,
    ):
        some_functionality()

Anyway, either one is superior to 'indent to sibling', where the lines are now tightly coupled to each other.

We each have different tastes, yes.

But, coding standards aren't about tastes, they are about coordinating large numbers of programmers to write code in consistent ways. PEP 8 gives the 'double indentation' as standard, rather than the 'K&R' style.

You're free to write however you want to, and if you're the tech director of a company, you can tell everyone else to follow your aesthetics. But you'll be doing a lot of work with code written according to PEP8. In my experience, learning and disciplining your team to use the standard is better than having a house-style. But YMMV, of course.

PEP8 isn't my 'ideal' aesthetic for Python either, but I'd need a far better reason than 'I think that looks ugly' for not using it.

I also agree 'indent to sibling' is poor, and not very universally tool-supported, even though it is part of the PEP8 style.