Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: allow line break at operators

Reply
Thread Tools

Re: allow line break at operators

 
 
Yingjie Lan
Guest
Posts: n/a
 
      08-10-2011
On Tue, Aug 9, 2011 at 9:42 PM, Yingjie Lan <(E-Mail Removed)> wrote:

> Hi all,
>
> When writing a long expresion, one usually would like to break it into multiple lines. Currently, you may use a '\' to do so, butit looks a little awkward (more like machine-oriented thing). Therefore I start wondering why not allow line breaking at an operator, which is the standard way of breaking a long expression in publication? Here is an example:
>
> #the old way
>
> x = 1+2+3+4+\
> ***** 1+2+3+4
>
> #the new way
> x = 1+2+3+4+ #line continues as it is clearly unfinished
>
> ***** 1+2+3+4


:# the currently allowed way
= (1+2+3+4+
:* * 1+2+3+4)
:# note the parentheses
:
:I think this is sufficient.

That works, but not in the most natural way--the way people are customed to...why require a pair of parenthis when we can do without them? Also, the new way does not affect the old ways of doingthings at all, it is fully backward compatible. So this just offers a new choice.

> Of course, the dot operator is also included, which may facilitate method chaining:
>
> x = svg.append( 'circle' ).
> ***** r(2).cx(1).xy(1).
> ***** foreground('black').bkground('white')


:Also, I dislike this for the dot operator especially, as it can
bscure whether a method call or a function call is taking place.

Again, this only offers a new choice, and does not force anybody to do it this way.

cheers,

Yingjie
 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      08-10-2011
On Wed, 10 Aug 2011 04:05 pm Yingjie Lan wrote:

> :# the currently allowed way
> = (1+2+3+4+
> :1+2+3+4)
> :# note the parentheses
> :
> :I think this is sufficient.
>
> That works, but not in the most natural way--the way people are customed
> to...why require a pair of parenthis when we can do without them?


Because it is better to be explicit that the line is still open. An opening
parenthesis or bracket that hasn't been closed is an explicit sign that the
line is still open. An operator is not.


> Also,
> the new way does not affect the old ways of doing things at all, it is
> fully backward compatible. So this just offers a new choice.


You say that as if having more choices is always good. It isn't. More
choices means more for people to learn, more complicated parser, more
options to consider, and more likelihood that errors will fail to raise
SyntaxError and instead go on to silently do the wrong thing. A new choice
should only be accepted when there is a clear and obvious benefit, not
merely because it will provide more choice.

Python is a programming language, not an ice cream shop.


>> Of course, the dot operator is also included, which may facilitate method
>> chaining:
>>
>> x = svg.append( 'circle' ).
>> r(2).cx(1).xy(1).
>> foreground('black').bkground('white')


If you are chaining six dots like that, you are in gross violation of the
Law Of Demeter. That is poor code, and should be discouraged, not
encouraged.


>
> :Also, I dislike this for the dot operator especially, as it can
> bscure whether a method call or a function call is taking place.
>
> Again, this only offers a new choice, and does not force anybody to do it
> this way.


But it does force people to read it, because some people will use it, and so
others will have to suffer for their poor judgement.



--
Steven

 
Reply With Quote
 
 
 
 
Chris Angelico
Guest
Posts: n/a
 
      08-10-2011
On Wed, Aug 10, 2011 at 9:32 AM, Steven D'Aprano
<(E-Mail Removed)> wrote:
>>> Of course, the dot operator is also included, which may facilitate method
>>> chaining:
>>>
>>> x = svg.append( 'circle' ).
>>> r(2).cx(1).xy(1).
>>> foreground('black').bkground('white')

>
> If you are chaining six dots like that, you are in gross violation of the
> Law Of Demeter. That is poor code, and should be discouraged, not
> encouraged.


I would only accept that this is poor code IF there is a viable
alternative, such as:

x = svg.append(circle(r=2,cx=1,xy=1,foreground='black' ,bkground='white'))

This would, imho, be a more Pythonic way to do it. But if this isn't
available, and if the methods already return self, then I see nothing
wrong with chaining. It's a handy way of getting additional mileage
out of lambdas and list comps when writing one-liners.

(Cue long thread about whether or not one-liners are Pythonic.)

Chris Angelico
 
Reply With Quote
 
Dan Sommers
Guest
Posts: n/a
 
      08-10-2011
On Wed, 10 Aug 2011 18:32:05 +1000, Steven D'Aprano wrote:

> Python is a programming language, not an ice cream shop.


+1 QOTW

How about a cheese shop?

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

I can see the "+" signs a lot easier there than at the end of some line,
where it might be buried between two longer lines:

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

 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      08-10-2011
On Wed, Aug 10, 2011 at 10:56 AM, Dan Sommers <(E-Mail Removed)> 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.
Putting the + at the end of the previous line at least prevents that,
since most unary operators bind to the operand on the right; but
there's still the potential for ambiguity.

When line breaks are significant, they cannot be randomly inserted
inside expressions.

ChrisA
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      08-10-2011
On Wed, Aug 10, 2011 at 1:25 PM, Duncan Booth
<(E-Mail Removed)> wrote:
> Chris Angelico <(E-Mail Removed)> wrote:
>
>> On Wed, Aug 10, 2011 at 10:56 AM, Dan Sommers <(E-Mail Removed)>
>> 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
 
Reply With Quote
 
Yingjie Lan
Guest
Posts: n/a
 
      08-10-2011
> On Wed, Aug 10, 2011 at 10:56 AM, Dan Sommers <(E-Mail Removed)>

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

This discussion leads me to this question:

Is it possible for python to allow free splitting of single-line statements
without the backslashes, if we impose that expressions can only be split
when it is not yet a finished expression? Note: splitting before closing
parenthis, brace, or bracket can be viewed as special case of this
more general rule..


Yingjie

 
Reply With Quote
 
Yingjie Lan
Guest
Posts: n/a
 
      08-10-2011
>> 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.


If ';' are employed (required), truely free line-splitting should be OK,
the operators may appear at the beginnings of the lines as you wish.

Yingjie

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      08-10-2011
Chris Angelico wrote:

> On Wed, Aug 10, 2011 at 10:56 AM, Dan Sommers <(E-Mail Removed)>
> 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.
> Putting the + at the end of the previous line at least prevents that,
> since most unary operators bind to the operand on the right;


Not so:

>>> x = (42 + -

.... 100)
>>>
>>> x

-58



--
Steven

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      08-10-2011
Dan Sommers 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))


Agreed.


--
Steven

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
allow line break at operators Yingjie Lan Python 1 08-10-2011 11:26 AM
`if (!p ? i++ : 0) break;' == `if (!p){ i++; break;}' ? lovecreatesbea...@gmail.com C Programming 12 04-14-2008 07:59 AM
newbie: allow deny vs deny allow Jeff ASP .Net 2 09-19-2006 02:12 AM
Read a file line by line with a maximum number of characters per line Hugo Java 10 10-18-2004 11:42 AM
Location element in the Web.config file. Allow System Admin whole directory, allow others specific page Ryan Taylor ASP .Net Security 1 09-09-2004 06:52 PM



Advertisments