PEP8 operator must come before line break
Hi, PEP8 says that: "The preferred place to break around a binary operator is after the operator, not before it." This is ignored in the multiline if examples, and seems to generally be a bad idea as it negatively impacts clarity. For example, the following seems much clearer as the entire line does not need to be scanned to see the intent- only the start of the line is needed to see how the different properties are used for filtering: mylist = [ item for item in mylist if item['property'] == 2 and item['otherproperty'] == 'test' ] The alternative seems less clear: mylist = [ item for item in mylist if item['property'] == 2 and item['otherproperty'] == 'test' ] If this recommendation remains in force, it would be good to: 1. Follow it in the style guide. 2. Provide a rationale for it, as currently it seems arbitrary and unhelpful. Just raising this as it has bitten me a couple of times with style checkers recently. Thanks, S
Where in PEP 8 does it violate its own advice? That's a bug. (The PEP has many authors by now.) As the PEP acknowledges, style is hard to agree over. It's even harder to change an agreement that has been documented (if not always followed consistently) for over 20 years. My rationale for this rule is that ending a line in a binary operator is a clear hint to the reader that the line isn't finished. (If you think about it, a comma is a kind of binary operator, and you wouldn't move the comma to the start of the continuation line, would you? :-) On Thu, Apr 14, 2016 at 9:25 AM, SW <walker_s@hotmail.co.uk> wrote:
-- --Guido van Rossum (python.org/~guido)
On Thu, Apr 14, 2016, at 12:35, Guido van Rossum wrote:
Well, yes, but "and" and "or" are English conjunctions in addition to being binary operators and, a line break is a natural break in reading and, something flows more naturally if you pause before conjunctions rather than after them or, am I completely wrong about that? What I'm saying is, maybe there should be a separate rule for "and" and "or" in certain contexts, rather than a universal rule for all binary operators.
Where in PEP 8 does it violate its own advice
As the OP did not reply this fast, from the webpage (/dev/peps/pep-0008) section indentation, just after 'Acceptable options in this situation include, but are not limited to: ' # Add some extra indentation on the conditional continuation line. if (this_is_one_thing and that_is_another_thing): do_something() That is the only place I could find just now.
Thanks, that was obviously an oversight. I've fixed the PEP. If the discussion ends up with rough consensus on changing this I will happily change it back (and change all other occurrences to match the new rule). Note that my request for "rough consensus" does *not* imply a vote. +1 and -1 votes (nor fractions in between) should not be posted -- however cogent arguments for/against the status quo (or for relinquishing the rule altogether) are welcome. On Thu, Apr 14, 2016 at 10:02 AM, Matthias welp <boekewurm@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)
That'll teach me for stepping away from the computer... As for changing an established rule, I agree that can be difficult. The reason this one became an irritation for me is that it was only in the last few months that I saw flake8 (my style complainer of choice) start complaining about this, so it's not quite so entrenched as other elements of style. I agree that placing the binary operator at the end shows the line should continue, and thus could be valid, but I also think that placing it at the start of the next line shows the logic flow for each part of the expression more clearly- as shown in the examples I originally gave. Thanks, S On 14/04/16 18:23, Guido van Rossum wrote:
I find the operator at the beginning of the line much more clear in code like this: innerWidth = (outerWidth - 2 * border_width - left_margin - right_margin) outerHeight = (innerHeight + (title_height if have_title else 0) + (subtitle_height if have_subtitle else 0) - (1 if have_title and have_subtitle else 0)) outerHeight = (innerHeight + (title_height if have_title else 0) + (subtitle_height if have_subtitle else 0) - (1 if have_title and have_subtitle else 0)) area = ((multiline_calculation_of_height) * (multiline_calculation_of_width)) The first two are taken and sanitized from real code. --- Bruce Check out my puzzle book and get it free here: http://J.mp/ingToConclusionsFree (available on iOS) On Thu, Apr 14, 2016 at 11:48 AM, SW <walker_s@hotmail.co.uk> wrote:
My preference has been towards having the binary operator at the front rather than end since listening to Brandon Rhodes 2012 PyCon Canada talk (specifically starting around [1]) . Specifically he is arguing that following Knuth rather than PEP 8 [2] might be a better way to go. Maybe my preference there is due to the Django work I was doing where I would get long query lines and didn’t always want to split them into multiple lines [3]: query = (Person.objects .filter(last_name==‘Smith’) .order_by('social_security_number') .select_related('spouse') ) [1] http://rhodesmill.org/brandon/slides/2012-11-pyconca/#id183 <http://rhodesmill.org/brandon/slides/2012-11-pyconca/#id183> [2] http://rhodesmill.org/brandon/slides/2012-11-pyconca/#knuth-instead-of-pep-8 <http://rhodesmill.org/brandon/slides/2012-11-pyconca/#knuth-instead-of-pep-8> [3] http://rhodesmill.org/brandon/slides/2012-11-pyconca/#option-3 <http://rhodesmill.org/brandon/slides/2012-11-pyconca/#option-3> ~ Ian Lee | IanLee1521@gmail.com <mailto:IanLee1521@gmail.com>
On 14/04/16 20:22, Serhiy Storchaka wrote:
Interesting. But that bug potentially exists regardless of what PEP8 says. This seems to me to be something that should be tackled separately. I imagine that there are versions of 'expr2' that makes this a valid and useful construct (which is why it remains) - if I've missed some historical discussion on this then please refer me to it, I'd like to understand what I'm missing on first glance. Thanks, E.
On Fri, Apr 15, 2016 at 5:41 AM, Erik <python@lucidity.plus.com> wrote:
Yes, but if you encourage people to spell it the first way, you can't accidentally leave part of your expression out of your result. However, I wouldn't write it like *either* of those. To me, the options are: result = expr1 + expr2 and result = expr1 + expr 2 And either of those would give an immediate IndentationError without the parentheses. So indenting the continuation is even better than choosing where to place the binary operator. ChrisA
On 14/04/16 21:04, Chris Angelico wrote:
Agreed, and the second one is how I prefer to format my C code too.
So indenting the continuation is even better than choosing where to place the binary operator.
The two are not mutually exclusive. Indenting the continuation tackles the "silent bug" issue, while choosing where to place the operator is purely a readability issue - hence I prefer the second of your examples ... it addresses both problems from my POV. However, that doesn't answer my question of when a line consisting of just "+ expr" is a useful thing. E.
On Thu, Apr 14, 2016 at 3:30 PM, Erik <python@lucidity.plus.com> wrote:
However, that doesn't answer my question of when a line consisting of just "+ expr" is a useful thing.
It's probably not, but that's for a linter to point out. For a stupid, contrived, untested example, though: class Foo: def __init__(self, value): self.value = value def __pos__(self): self.value += 1 def __neg__(self): self.value -= 2 f = Foo(3) +f assert f.value == 4 -f assert f.value == 2 -- Zach
Hi Zach, On 14/04/16 21:41, Zachary Ware wrote:
It's probably not, but that's for a linter to point out.
I was waiting for the "linter" response (in a good way - I suspected that would eventually be the answer, but I was hoping to be surprised :)).
stupid, contrived, untested example, though:
Yeah, OK. In nearly 20 years, I've never once needed to implement those dunder methods, but that's explanation enough for me - thanks. E.
On Thu, Apr 14, 2016, at 16:30, Erik wrote:
However, that doesn't answer my question of when a line consisting of just "+ expr" is a useful thing.
Well, it's a legitimate unary operator. I've never heard a good explanation of what the point of it is, but the same can't be said obviously for -expr. As for allowing an expression on its own (sure, any operator _can_ have side effects, but calling most operators for their side effects is a huge stylistic problem with the code regardless)... the same can be said for most operators, not just the unary + and -. It'd probably be reasonable to make a static checking tool that gives you warnings if almost any non-function-call expression is used as a statement. (along with other things like most constructors, pure functions, etc). But I think the idea of making it a syntax error has actually been brought up recently and rejected.
On Thu, Apr 14, 2016 at 09:30:56PM +0100, Erik wrote:
However, that doesn't answer my question of when a line consisting of just "+ expr" is a useful thing.
Almost nowhere. But, if you have a DSL that operates in a imperative fashion (giving commands, rather than returning results in a functional fashion) you might do something like: +tracing command() command() -tracing which is modelled after the doctest directives: # doctest: +SKIP # doctest: -NORMALIZE_WHITESPACE etc. I don't think this imperative style is a really good fit for Python's syntax, but it could work for some people. -- Steve
On 14/04/16 18:23, Guido van Rossum wrote:
Interestingly, the sentence above specifically binds the 'and' with what follows, via parentheses. It is not part of the preceding text to indicate something follows ...
however cogent arguments for/against the status quo (or for relinquishing the rule altogether) are welcome.
What I said above pretty much sums up my argument for this (it came up in a different context a month or so ago). I think that is also Matthias's argument (though I won't speak for him). English speakers will not usually accentuate the 'and's and 'or's in a sentence before pausing. To me, I read: if foo == bar and \ baz == spam: as: "if foo equals bar AND, baz equals spam". (emphasis on the "and", a pause before 'baz'). Where I will read: if foo == bar \ and baz == spam: as: "If foo equals bar, and baz equals spam" (pause after 'bar'). Just my personal opinion. The problem with this sort of style issue is that it's a pattern-based thing. If one is used to reading code written with a particular pattern then it's hard to adjust to another. So I don't think you'll get a complete consensus one way or the other. E.
On 4/14/2016 1:23 PM, Guido van Rossum wrote:
however cogent arguments for/against the status quo (or for relinquishing the rule altogether) are welcome.
Outside of Python, binary operators are (in the examples I can think of) more often more strongly associated with the second argument than the first, even to the point of switching the order of 2nd arg and operator. English: Start with A, add B, subtract C, and assign the result to D. Assembly: load A add B sub C stor D Calculator tape (with literals, not symbols) A B + C - D = I suggest relinquishing the rule, except maybe to suggest consistency within an expression, if not the whole file. -- Terry Jan Reedy
Guido van Rossum <guido@...> writes:
I personally tend to look more at the start of the lines because that's where the blocks are defined (by indentation). Also the end of the lines are usually not aligned which makes binary operators harder to see. Because of these two reasons I always put binary operator at the start of new lines, because that's where I have the most chance to see them, and I'm in favor of changing this in PEP8.
On Thu, Apr 14, 2016 at 12:28 PM, Joseph Martinot-Lagarde < contrebasse@gmail.com> wrote:
This is the case that jumped to mind for me as well... If I saw code like this in a code review I'd force the author to change it because the style is outright misleading: return (something1() + a * b + some_other_thing() ** 2 - f - normalizer) We're summing a list of items with some things being negated, but that structure is impossible to see, and worst of all, the association between the operator and the thing being operated on is totally lost. OTOH if we write like this: return (something1() + a * b + some_other_thing() ** 2 - f - normalizer) then the list structure is immediately obvious, and it's immediately obvious which terms are being added and which are being subtracted. Similarly, who can even tell if this code is correct: return (something1() + a * b + some_other_thing() ** 2 - f / normalizer) but if the same code is formatted this way then it's immediately obvious that the code is buggy: return (something1() + a * b + some_other_thing() ** 2 - f / normalizer) It should be corrected to: return ((something1() + a * b + some_other_thing() ** 2 - f) / normalizer) (I'm calling the final item "normalizer" because this pattern actually comes up fairly often in bayesian computations -- if you're working in log space then at the end of some computation you subtract off a magic normalizing factor, and if you're working in linear space then at the end you divide off a magic normalizing factor. You can also get a similar pattern for chains of * and /, though it's less common.) In all of these cases, the hanging indent makes the fact that we have a continuation line obvious from across the room -- I don't need help knowing that there's a continuation, I need help figuring out what the the computation actually does :-). I actually find a similar effect for and/or chains, where the beginning-of-line format makes things lined up and easier to scan -- e.g. comparing these two options: return (something1() and f() and some_expression > 1 and (some_other_thing() == whatever or blahblah or asdf)) return (something1() and f() and some_expression > 1 and (some_other_thing() == whatever or blahblah or asdf)) then I find the second option dramatically more readable. But maybe that's just me -- for and/or the argument is a bit less compelling, because you don't regularly have chains of different operators with the same precedence, like you do with +/-. I guess this might have to do with a more underlying stylistic difference: as soon as I have an expression that stretches across multiple lines, I try to break it into pieces where each line is a meaningful unit, even if this doesn't produce the minimum number of lines. For example I generally avoid writing stuff like: return (something1() and f() some_expression > 1 and (some_other_thing() == whatever or blahblah or asdf)) return (something1() + a * b + some_other_thing() ** 2 - f - normalizer) -n BIKESHEDDING REDUCTION ACT NOTICE: I hereby swear that I have said everything useful I have to say about this topic and that this will be my only contribution to this thread unless someone addresses me directly. -- Nathaniel J. Smith -- https://vorpus.org
On 04/14/2016 05:45 PM, Nathaniel Smith wrote:
On Thu, Apr 14, 2016 at 12:28 PM, Joseph Martinot-Lagarde wrote:
I agree. ;) Most of my continuation lines are with `and` and `or`, and I try to keep the logical pieces on one line with the join `and` or `or` beginning the next line. Much easier for me to read. -- ~Ethan~
OK, I get it. Brandon's slides with the Knuth references were especially useful. So let's change the PEP! Who wants to draft a diff? -- --Guido van Rossum (python.org/~guido)
http://bugs.python.org/issue26763 <http://bugs.python.org/issue26763> ~ Ian Lee | IanLee1521@gmail.com <mailto:IanLee1521@gmail.com>
On Apr 14, 2016, at 05:25 PM, SW wrote:
PEP8 says that: "The preferred place to break around a binary operator is after the operator, not before it."
Personally, my own preferred style prefers keyword binary operators, e.g. 'and' and 'or', after the line break but operator symbols (e.g. '*' or '+') before the line break. The way my editor syntax highlights the keywords but not the operators makes this style the most readable to me. However, I think the pep8 tool is too strict here. PEP 8 the document doesn't say the line break around binary operators is *required* just that it's a preferred style. Forcing the line break here seems like the tool is overstepping and I would favor a relaxation of the tool. Where I've adopted flake8 and such, I've grumbled when it forces me to make this change. (But I guess not enough to file a bug. ;) If the pep8 developers insist on reading PEP 8's "preferred" as a strict requirement, then I would favor clarification in PEP 8 that such line breaks are not required and that either choice of line break positioning around binary operators is acceptable. Cheers, -Barry
Where in PEP 8 does it violate its own advice? That's a bug. (The PEP has many authors by now.) As the PEP acknowledges, style is hard to agree over. It's even harder to change an agreement that has been documented (if not always followed consistently) for over 20 years. My rationale for this rule is that ending a line in a binary operator is a clear hint to the reader that the line isn't finished. (If you think about it, a comma is a kind of binary operator, and you wouldn't move the comma to the start of the continuation line, would you? :-) On Thu, Apr 14, 2016 at 9:25 AM, SW <walker_s@hotmail.co.uk> wrote:
-- --Guido van Rossum (python.org/~guido)
On Thu, Apr 14, 2016, at 12:35, Guido van Rossum wrote:
Well, yes, but "and" and "or" are English conjunctions in addition to being binary operators and, a line break is a natural break in reading and, something flows more naturally if you pause before conjunctions rather than after them or, am I completely wrong about that? What I'm saying is, maybe there should be a separate rule for "and" and "or" in certain contexts, rather than a universal rule for all binary operators.
Where in PEP 8 does it violate its own advice
As the OP did not reply this fast, from the webpage (/dev/peps/pep-0008) section indentation, just after 'Acceptable options in this situation include, but are not limited to: ' # Add some extra indentation on the conditional continuation line. if (this_is_one_thing and that_is_another_thing): do_something() That is the only place I could find just now.
Thanks, that was obviously an oversight. I've fixed the PEP. If the discussion ends up with rough consensus on changing this I will happily change it back (and change all other occurrences to match the new rule). Note that my request for "rough consensus" does *not* imply a vote. +1 and -1 votes (nor fractions in between) should not be posted -- however cogent arguments for/against the status quo (or for relinquishing the rule altogether) are welcome. On Thu, Apr 14, 2016 at 10:02 AM, Matthias welp <boekewurm@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)
That'll teach me for stepping away from the computer... As for changing an established rule, I agree that can be difficult. The reason this one became an irritation for me is that it was only in the last few months that I saw flake8 (my style complainer of choice) start complaining about this, so it's not quite so entrenched as other elements of style. I agree that placing the binary operator at the end shows the line should continue, and thus could be valid, but I also think that placing it at the start of the next line shows the logic flow for each part of the expression more clearly- as shown in the examples I originally gave. Thanks, S On 14/04/16 18:23, Guido van Rossum wrote:
I find the operator at the beginning of the line much more clear in code like this: innerWidth = (outerWidth - 2 * border_width - left_margin - right_margin) outerHeight = (innerHeight + (title_height if have_title else 0) + (subtitle_height if have_subtitle else 0) - (1 if have_title and have_subtitle else 0)) outerHeight = (innerHeight + (title_height if have_title else 0) + (subtitle_height if have_subtitle else 0) - (1 if have_title and have_subtitle else 0)) area = ((multiline_calculation_of_height) * (multiline_calculation_of_width)) The first two are taken and sanitized from real code. --- Bruce Check out my puzzle book and get it free here: http://J.mp/ingToConclusionsFree (available on iOS) On Thu, Apr 14, 2016 at 11:48 AM, SW <walker_s@hotmail.co.uk> wrote:
My preference has been towards having the binary operator at the front rather than end since listening to Brandon Rhodes 2012 PyCon Canada talk (specifically starting around [1]) . Specifically he is arguing that following Knuth rather than PEP 8 [2] might be a better way to go. Maybe my preference there is due to the Django work I was doing where I would get long query lines and didn’t always want to split them into multiple lines [3]: query = (Person.objects .filter(last_name==‘Smith’) .order_by('social_security_number') .select_related('spouse') ) [1] http://rhodesmill.org/brandon/slides/2012-11-pyconca/#id183 <http://rhodesmill.org/brandon/slides/2012-11-pyconca/#id183> [2] http://rhodesmill.org/brandon/slides/2012-11-pyconca/#knuth-instead-of-pep-8 <http://rhodesmill.org/brandon/slides/2012-11-pyconca/#knuth-instead-of-pep-8> [3] http://rhodesmill.org/brandon/slides/2012-11-pyconca/#option-3 <http://rhodesmill.org/brandon/slides/2012-11-pyconca/#option-3> ~ Ian Lee | IanLee1521@gmail.com <mailto:IanLee1521@gmail.com>
On 14/04/16 20:22, Serhiy Storchaka wrote:
Interesting. But that bug potentially exists regardless of what PEP8 says. This seems to me to be something that should be tackled separately. I imagine that there are versions of 'expr2' that makes this a valid and useful construct (which is why it remains) - if I've missed some historical discussion on this then please refer me to it, I'd like to understand what I'm missing on first glance. Thanks, E.
On Fri, Apr 15, 2016 at 5:41 AM, Erik <python@lucidity.plus.com> wrote:
Yes, but if you encourage people to spell it the first way, you can't accidentally leave part of your expression out of your result. However, I wouldn't write it like *either* of those. To me, the options are: result = expr1 + expr2 and result = expr1 + expr 2 And either of those would give an immediate IndentationError without the parentheses. So indenting the continuation is even better than choosing where to place the binary operator. ChrisA
On 14/04/16 21:04, Chris Angelico wrote:
Agreed, and the second one is how I prefer to format my C code too.
So indenting the continuation is even better than choosing where to place the binary operator.
The two are not mutually exclusive. Indenting the continuation tackles the "silent bug" issue, while choosing where to place the operator is purely a readability issue - hence I prefer the second of your examples ... it addresses both problems from my POV. However, that doesn't answer my question of when a line consisting of just "+ expr" is a useful thing. E.
On Thu, Apr 14, 2016 at 3:30 PM, Erik <python@lucidity.plus.com> wrote:
However, that doesn't answer my question of when a line consisting of just "+ expr" is a useful thing.
It's probably not, but that's for a linter to point out. For a stupid, contrived, untested example, though: class Foo: def __init__(self, value): self.value = value def __pos__(self): self.value += 1 def __neg__(self): self.value -= 2 f = Foo(3) +f assert f.value == 4 -f assert f.value == 2 -- Zach
Hi Zach, On 14/04/16 21:41, Zachary Ware wrote:
It's probably not, but that's for a linter to point out.
I was waiting for the "linter" response (in a good way - I suspected that would eventually be the answer, but I was hoping to be surprised :)).
stupid, contrived, untested example, though:
Yeah, OK. In nearly 20 years, I've never once needed to implement those dunder methods, but that's explanation enough for me - thanks. E.
On Thu, Apr 14, 2016, at 16:30, Erik wrote:
However, that doesn't answer my question of when a line consisting of just "+ expr" is a useful thing.
Well, it's a legitimate unary operator. I've never heard a good explanation of what the point of it is, but the same can't be said obviously for -expr. As for allowing an expression on its own (sure, any operator _can_ have side effects, but calling most operators for their side effects is a huge stylistic problem with the code regardless)... the same can be said for most operators, not just the unary + and -. It'd probably be reasonable to make a static checking tool that gives you warnings if almost any non-function-call expression is used as a statement. (along with other things like most constructors, pure functions, etc). But I think the idea of making it a syntax error has actually been brought up recently and rejected.
On Thu, Apr 14, 2016 at 09:30:56PM +0100, Erik wrote:
However, that doesn't answer my question of when a line consisting of just "+ expr" is a useful thing.
Almost nowhere. But, if you have a DSL that operates in a imperative fashion (giving commands, rather than returning results in a functional fashion) you might do something like: +tracing command() command() -tracing which is modelled after the doctest directives: # doctest: +SKIP # doctest: -NORMALIZE_WHITESPACE etc. I don't think this imperative style is a really good fit for Python's syntax, but it could work for some people. -- Steve
On 14/04/16 18:23, Guido van Rossum wrote:
Interestingly, the sentence above specifically binds the 'and' with what follows, via parentheses. It is not part of the preceding text to indicate something follows ...
however cogent arguments for/against the status quo (or for relinquishing the rule altogether) are welcome.
What I said above pretty much sums up my argument for this (it came up in a different context a month or so ago). I think that is also Matthias's argument (though I won't speak for him). English speakers will not usually accentuate the 'and's and 'or's in a sentence before pausing. To me, I read: if foo == bar and \ baz == spam: as: "if foo equals bar AND, baz equals spam". (emphasis on the "and", a pause before 'baz'). Where I will read: if foo == bar \ and baz == spam: as: "If foo equals bar, and baz equals spam" (pause after 'bar'). Just my personal opinion. The problem with this sort of style issue is that it's a pattern-based thing. If one is used to reading code written with a particular pattern then it's hard to adjust to another. So I don't think you'll get a complete consensus one way or the other. E.
On 4/14/2016 1:23 PM, Guido van Rossum wrote:
however cogent arguments for/against the status quo (or for relinquishing the rule altogether) are welcome.
Outside of Python, binary operators are (in the examples I can think of) more often more strongly associated with the second argument than the first, even to the point of switching the order of 2nd arg and operator. English: Start with A, add B, subtract C, and assign the result to D. Assembly: load A add B sub C stor D Calculator tape (with literals, not symbols) A B + C - D = I suggest relinquishing the rule, except maybe to suggest consistency within an expression, if not the whole file. -- Terry Jan Reedy
Guido van Rossum <guido@...> writes:
I personally tend to look more at the start of the lines because that's where the blocks are defined (by indentation). Also the end of the lines are usually not aligned which makes binary operators harder to see. Because of these two reasons I always put binary operator at the start of new lines, because that's where I have the most chance to see them, and I'm in favor of changing this in PEP8.
On Thu, Apr 14, 2016 at 12:28 PM, Joseph Martinot-Lagarde < contrebasse@gmail.com> wrote:
This is the case that jumped to mind for me as well... If I saw code like this in a code review I'd force the author to change it because the style is outright misleading: return (something1() + a * b + some_other_thing() ** 2 - f - normalizer) We're summing a list of items with some things being negated, but that structure is impossible to see, and worst of all, the association between the operator and the thing being operated on is totally lost. OTOH if we write like this: return (something1() + a * b + some_other_thing() ** 2 - f - normalizer) then the list structure is immediately obvious, and it's immediately obvious which terms are being added and which are being subtracted. Similarly, who can even tell if this code is correct: return (something1() + a * b + some_other_thing() ** 2 - f / normalizer) but if the same code is formatted this way then it's immediately obvious that the code is buggy: return (something1() + a * b + some_other_thing() ** 2 - f / normalizer) It should be corrected to: return ((something1() + a * b + some_other_thing() ** 2 - f) / normalizer) (I'm calling the final item "normalizer" because this pattern actually comes up fairly often in bayesian computations -- if you're working in log space then at the end of some computation you subtract off a magic normalizing factor, and if you're working in linear space then at the end you divide off a magic normalizing factor. You can also get a similar pattern for chains of * and /, though it's less common.) In all of these cases, the hanging indent makes the fact that we have a continuation line obvious from across the room -- I don't need help knowing that there's a continuation, I need help figuring out what the the computation actually does :-). I actually find a similar effect for and/or chains, where the beginning-of-line format makes things lined up and easier to scan -- e.g. comparing these two options: return (something1() and f() and some_expression > 1 and (some_other_thing() == whatever or blahblah or asdf)) return (something1() and f() and some_expression > 1 and (some_other_thing() == whatever or blahblah or asdf)) then I find the second option dramatically more readable. But maybe that's just me -- for and/or the argument is a bit less compelling, because you don't regularly have chains of different operators with the same precedence, like you do with +/-. I guess this might have to do with a more underlying stylistic difference: as soon as I have an expression that stretches across multiple lines, I try to break it into pieces where each line is a meaningful unit, even if this doesn't produce the minimum number of lines. For example I generally avoid writing stuff like: return (something1() and f() some_expression > 1 and (some_other_thing() == whatever or blahblah or asdf)) return (something1() + a * b + some_other_thing() ** 2 - f - normalizer) -n BIKESHEDDING REDUCTION ACT NOTICE: I hereby swear that I have said everything useful I have to say about this topic and that this will be my only contribution to this thread unless someone addresses me directly. -- Nathaniel J. Smith -- https://vorpus.org
On 04/14/2016 05:45 PM, Nathaniel Smith wrote:
On Thu, Apr 14, 2016 at 12:28 PM, Joseph Martinot-Lagarde wrote:
I agree. ;) Most of my continuation lines are with `and` and `or`, and I try to keep the logical pieces on one line with the join `and` or `or` beginning the next line. Much easier for me to read. -- ~Ethan~
OK, I get it. Brandon's slides with the Knuth references were especially useful. So let's change the PEP! Who wants to draft a diff? -- --Guido van Rossum (python.org/~guido)
http://bugs.python.org/issue26763 <http://bugs.python.org/issue26763> ~ Ian Lee | IanLee1521@gmail.com <mailto:IanLee1521@gmail.com>
On Apr 14, 2016, at 05:25 PM, SW wrote:
PEP8 says that: "The preferred place to break around a binary operator is after the operator, not before it."
Personally, my own preferred style prefers keyword binary operators, e.g. 'and' and 'or', after the line break but operator symbols (e.g. '*' or '+') before the line break. The way my editor syntax highlights the keywords but not the operators makes this style the most readable to me. However, I think the pep8 tool is too strict here. PEP 8 the document doesn't say the line break around binary operators is *required* just that it's a preferred style. Forcing the line break here seems like the tool is overstepping and I would favor a relaxation of the tool. Where I've adopted flake8 and such, I've grumbled when it forces me to make this change. (But I guess not enough to file a bug. ;) If the pep8 developers insist on reading PEP 8's "preferred" as a strict requirement, then I would favor clarification in PEP 8 that such line breaks are not required and that either choice of line break positioning around binary operators is acceptable. Cheers, -Barry
participants (16)
-
Barry Warsaw -
Bruce Leban -
Chris Angelico -
Erik -
Ethan Furman -
Guido van Rossum -
Ian Lee -
Joseph Martinot-Lagarde -
Matthias welp -
Nathaniel Smith -
Random832 -
Serhiy Storchaka -
Steven D'Aprano -
SW -
Terry Reedy -
Zachary Ware