allow line break at operators

Chris Angelico rosuav at gmail.com
Wed Aug 10 08:42:30 EDT 2011


On Wed, Aug 10, 2011 at 1:25 PM, Duncan Booth
<duncan.booth at invalid.invalid> wrote:
> Chris Angelico <rosuav at gmail.com> wrote:
>
>> On Wed, Aug 10, 2011 at 10:56 AM, Dan Sommers <dan at tombstonezero.net>
>> wrote:
>>> In terms of easier to read, I find code easier to read when the
>>> operators are at the beginnings of the lines (PEP 8 notwithstanding):
>>>
>>>    x = (someobject.somemethod(object3, thing)
>>>         + longfunctionname(object2)
>>>         + otherfunction(value1, value2, value3))
>>>
>>
>> Without the parentheses, this is legal but (probably) useless; it
>> applies the unary + operator to the return value of those functions.
>
> No, in some other languages it might be legal, but this is Python.
> without the parentheses it is a syntax error.

It would be parsed as three separate statements. The only reason it
would be a syntax error would be because of the indentation, which is
not what I'd call reliable; it happens to catch this case, because
assignment doesn't allow subsequent lines to be indented, but nothing
forces continuation lines to be indented.

x = (5
+4)

x = 5
+4

What we have is a strangeness that can arise when a programmer ignores
something that is often insignificant; spare parentheses usually don't
matter.

Another potential danger is the similarity with tuple creation:

x = (someobject.somemethod(object3, thing)
     + longfunctionname(object2)
     + otherfunction(value1, value2, value3),)

This is a tuple with one element. Not too bad with the + operator, but
imagine if everything's done with method chaining on . which results
in the , being nearly indistinguishable. Not an insurmountable
problem, but a potential risk.

ChrisA



More information about the Python-list mailing list