Re: allow line break at operators

Discussion in 'Python' started by Yingjie Lan, Aug 10, 2011.

  1. Yingjie Lan

    Yingjie Lan Guest

    On Tue, Aug 9, 2011 at 9:42 PM, Yingjie Lan <> 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
    :x = (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
    :eek: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
    Yingjie Lan, Aug 10, 2011
    #1
    1. Advertising

  2. On Wed, 10 Aug 2011 04:05 pm Yingjie Lan wrote:

    > :# the currently allowed way
    > :x = (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
    > :eek: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
    Steven D'Aprano, Aug 10, 2011
    #2
    1. Advertising

  3. On Wed, Aug 10, 2011 at 9:32 AM, Steven D'Aprano
    <> 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
    Chris Angelico, Aug 10, 2011
    #3
  4. Yingjie Lan

    Dan Sommers Guest

    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
    Dan Sommers, Aug 10, 2011
    #4
  5. On Wed, Aug 10, 2011 at 10:56 AM, 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))
    >


    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
    Chris Angelico, Aug 10, 2011
    #5
  6. On Wed, Aug 10, 2011 at 1:25 PM, Duncan Booth
    <> wrote:
    > Chris Angelico <> wrote:
    >
    >> On Wed, Aug 10, 2011 at 10:56 AM, 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))
    >>>

    >>
    >> 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
    Chris Angelico, Aug 10, 2011
    #6
  7. Yingjie Lan

    Yingjie Lan Guest

    > On Wed, Aug 10, 2011 at 10:56 AM, 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))
    >>

    >
    > 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
    Yingjie Lan, Aug 10, 2011
    #7
  8. Yingjie Lan

    Yingjie Lan Guest

    >> 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
    Yingjie Lan, Aug 10, 2011
    #8
  9. Chris Angelico wrote:

    > On Wed, Aug 10, 2011 at 10:56 AM, 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))
    >>

    >
    > 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
    Steven D'Aprano, Aug 10, 2011
    #9
  10. 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
    Steven D'Aprano, Aug 10, 2011
    #10
  11. On Wed, Aug 10, 2011 at 1:58 PM, Yingjie Lan <> wrote:
    > 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?


    The trouble is that in a lot of cases, the next statement after an
    unfinished expression could conceivably be a continuation of it. If
    this were permitted, it would have to also require that the
    continuation lines be indented, to avoid the problem described above.
    It'd still have the potential to mis-diagnose errors, though.

    ChrisA
    Chris Angelico, Aug 10, 2011
    #11
  12. On Wed, Aug 10, 2011 at 3:37 PM, Steven D'Aprano
    <> wrote:
    >> 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


    Your unary - is binding to the operand to its right, in this case the
    100. (I think I have left and right correct; being in theatre has a
    tendency to make you forget which is which.) Your + is binary,
    operating on 42 and the result of applying unary - to 100, which is
    -100.

    My point about binding can be illustrated by inventing an operator @.
    Let's say that a@b is the atan2 of a and b, and x@ is x factorial (I
    can't imagine what deranged mind would do something like this, apart
    from my own).

    y = 5 @ # 120, as per factorial
    x = 5 @ 2 # 1.19 or so, as per atan2
    foo(123) # Calls foo() and discards its return value
    z = 5 @
    foo(123)

    Is that last example one statement or two?

    But this situation shouldn't ever occur in Python, because all its
    unary operators (not, -, +, ~) bind to the operand to their right (I
    don't think there's any I've missed, are there?). It does mean,
    however, that a leading operator is not unambiguous. Without the
    surrounding parentheses and/or otherwise-unexpected indentation, an
    expression beginning with a + could conceivably be applying the unary
    plus operator to the rest of the expression, rather than implying that
    it's continuing the previous line.

    Chris Angelico
    Chris Angelico, Aug 10, 2011
    #12
  13. Yingjie Lan

    Ian Kelly Guest

    On Wed, Aug 10, 2011 at 8:37 AM, Steven D'Aprano
    <> wrote:
    >> 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


    That is still binding to the operand on the "right" (i.e., the
    sequentially later). And it still does not cause the problem that
    Chris was talking about, since without the parentheses that would be a
    syntax error. So I guess I'm not certain what exactly it is that
    you're trying to demonstrate here.
    Ian Kelly, Aug 10, 2011
    #13
  14. On Wed, Aug 10, 2011 at 2:19 PM, Yingjie Lan <> wrote:
    > If ';' are employed (required), truely free line-splitting should be OK,
    > the operators may appear at the beginnings of the lines as you wish.
    >


    And if we require {} then truly free indentation should be OK too! But
    it wouldn't be Python any more.

    ChrisA
    Chris Angelico, Aug 10, 2011
    #14
  15. Yingjie Lan

    Seebs Guest

    On 2011-08-10, Chris Angelico <> wrote:
    > And if we require {} then truly free indentation should be OK too! But
    > it wouldn't be Python any more.


    Would it really not be Python at all?

    I've seen bits of code in preprocessing-based "Python with {}" type things,
    and they still look like Python to me, only they favor explicit over
    implicit a little more strongly.

    -s
    --
    Copyright 2011, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
    Seebs, Aug 10, 2011
    #15
  16. On Wed, Aug 10, 2011 at 10:51 PM, Ben Finney <> wrote:
    > Seebs <> writes:
    >> I've seen bits of code in preprocessing-based "Python with {}" type
    >> things, and they still look like Python to me, only they favor
    >> explicit over implicit a little more strongly.

    >
    > They introduce unnecessary ambiguity: the indentation-as-structure and
    > braces-as-structure can then disagree.
    >
    > The ambiguity is resolved by having exactly one of indentation or braces
    > determining structure: Python uses indentation. In which case, braces
    > are pointless for indicating block structure.


    That's why it wouldn't be Python. It would have to use the braces and
    not the indentation.

    ChrisA
    PS. I mistakenly sent this to a Gilbert & Sullivan group first. Oddly
    enough, opera-goers are not used to discussing the relative merits of
    braces vs indentation in code.
    Chris Angelico, Aug 10, 2011
    #16
  17. Yingjie Lan

    Tim Chase Guest

    Tim Chase, Aug 11, 2011
    #17
  18. Ian Kelly wrote:

    > On Wed, Aug 10, 2011 at 8:37 AM, Steven D'Aprano
    > <> wrote:
    >>> 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

    >
    > That is still binding to the operand on the "right" (i.e., the
    > sequentially later). And it still does not cause the problem that
    > Chris was talking about, since without the parentheses that would be a
    > syntax error. So I guess I'm not certain what exactly it is that
    > you're trying to demonstrate here.


    Chris stated that putting the unary + at the end of the line
    prevents "that", that being applying the unary + operator to the value on
    the right. But that is not the case -- unary prefix operators in Python can
    be separated from their operands by whitespace, including newlines.

    (Python doesn't have any unary postfix operators.)



    --
    Steven
    Steven D'Aprano, Aug 11, 2011
    #18
  19. Re: Python & Sullivan

    On Thu, Aug 11, 2011 at 12:26 AM, Tim Chase
    <> wrote:
    > On 08/10/2011 05:42 PM, Chris Angelico wrote:
    >>
    >> PS. I mistakenly sent this to a Gilbert&  Sullivan group
    >> first. Oddly enough, opera-goers are not used to discussing
    >> the relative merits of braces vs indentation in code.

    >
    > It's only fair turnabout:
    >
    > http://coding.derkeiler.com/Archive/Python/comp.lang.python/2006-09/msg01783.html


    Yes, I know about that one. My problem is that I snap off quick
    responses to both lists, and sometimes type "sav" instead of "py" or
    vice versa. Usually I catch it before hitting Send, though!!

    On MUDs, we call that a mischannel. I've now mischanneled both directions. :|

    ChrisA
    Chris Angelico, Aug 11, 2011
    #19
  20. On Thu, Aug 11, 2011 at 12:32 AM, Steven D'Aprano
    <> wrote:
    > Chris stated that putting the unary + at the end of the line
    > prevents "that", that being applying the unary + operator to the value on
    > the right. But that is not the case -- unary prefix operators in Python can
    > be separated from their operands by whitespace, including newlines.
    >


    Right, I forgot that. It certainly would not be normal to do it that
    way, though.

    ChrisA
    Chris Angelico, Aug 11, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Hugo
    Replies:
    10
    Views:
    1,299
    Matt Humphrey
    Oct 18, 2004
  2. Jeff
    Replies:
    2
    Views:
    941
    clintonG
    Sep 19, 2006
  3. Replies:
    12
    Views:
    955
  4. Yingjie Lan

    allow line break at operators

    Yingjie Lan, Aug 10, 2011, in forum: Python
    Replies:
    1
    Views:
    180
    TheSaint
    Aug 10, 2011
  5. Ryan Taylor
    Replies:
    1
    Views:
    682
    Ryan Taylor
    Sep 9, 2004
Loading...

Share This Page