Ian Lee added the comment:

> 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] 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

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to