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