> Aren't there many other examples in the PEP that need to be adjusted, since we're changing the style not just for 'and' and 'or' but for all binary operators?

Admittedly I'd only looked in that one section last night, but I just went through the PEP and didn't see any other when I just went through the entire PEP now...

> I also think the PEP needs some language about the previous style being still acceptable as long as it's being used consistently (Knuth notwithstanding), and an acceptable compromise style where and/or go at the start of the line but other binary operators stay at the end.

I'd updated my branch on GitHub [1] but Guido, you beat me to the update while I was typing this message!

> I don't like the way "):" is indented in that example.

Honestly I don't either, I just like it more than artificially pushing the other lines forward a space. Personally, I'm not a fan of the current change either which puts the raise in line with the condition logic for the `if`::

        if (width == 0
            and height == 0
            and color == 'red'
            and emphasis == 'strong'
            or highlight > 100):
            raise ValueError("sorry, you lose")


My preference is to actually break that logic up and avoid the wrapping in the first place, as in [2]. Which in this particular class has the side benefit of that value being used again in the same function anyways.

I'm starting to realize that Brandon Rhodes really had a big impact on my ideas of styling as I've been learning Python these past few years, as this was another one style I'm stealing from that same talk [3].

> I've updated the PEP...

Great, thanks! I've created a ticket in pycodestyle [4] to update the style checker, which in turn will fix the flake8 error downstream once I get around (hopefully before PyCon) to releasing pycodestyle 1.8.0

[1] issue26763">https://github.com/python/peps/compare/master...IanLee1521:issue26763
[2] https://github.com/python/peps/commit/0c790e7b721bd13ad12ab9e6f6206836f398f9c4
[3] http://rhodesmill.org/brandon/slides/2012-11-pyconca/#naming-intermediate-values
[4] https://github.com/PyCQA/pycodestyle/issues/498