On Thu, Apr 14, 2016, at 12:35, Guido van Rossum wrote:

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? :-)

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.

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:

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:

...

...

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.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

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 Apr 14, 2016, at 11:48, SW <walker_s@hotmail.co.uk> wrote:

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:

...

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:

...

...

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.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 14/04/16 20:22, Serhiy Storchaka wrote:

An argument for operators "+" and "-":

result = expr1 + expr2

is syntax error, while

result = expr1 + expr2

is silent bug.

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 14/04/16 21:04, Chris Angelico wrote:

However, I wouldn't write it like *either* of those. To me, the options are:

result = expr1 + expr2

and

result = expr1 + expr 2

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.

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

On Thu, Apr 14, 2016 at 12:28 PM, Joseph Martinot-Lagarde < contrebasse@gmail.com> wrote:

Guido van Rossum <guido@...> writes:

...

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?

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.

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

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)