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.
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.
The only caveat, also covered in PEP 8 is for function definitions.
becomes i.e. the parameter lines are double indented.