line continuation for lines ending in "and" or "or"

Discussion in 'Python' started by Russ P., Jun 5, 2008.

  1. Russ P.

    Russ P. Guest

    I've always appreciated Python's lack of requirement for a semi-colon
    at the end of each line. I also appreciate its rules for automatic
    line continuation. If a statement ends with a "+", for example, Python
    recognizes that the statement obviously must continue.

    I've noticed, however, that the same rule does not apply when a line
    ends with "and," "or," or "not." Yes, it's a minor point, but
    shouldn't the same rule apply?

    Seems like it would be easy to add.
    Russ P., Jun 5, 2008
    #1
    1. Advertising

  2. Russ P.

    Dan Bishop Guest

    On Jun 4, 10:09 pm, "Russ P." <> wrote:
    > I've always appreciated Python's lack of requirement for a semi-colon
    > at the end of each line. I also appreciate its rules for automatic
    > line continuation. If a statement ends with a "+", for example, Python
    > recognizes that the statement obviously must continue.
    >
    > I've noticed, however, that the same rule does not apply when a line
    > ends with "and," "or," or "not." Yes, it's a minor point, but
    > shouldn't the same rule apply?
    >
    > Seems like it would be easy to add.


    Huh? This doesn't work either:

    >>> x = 2 +

    File "<stdin>", line 1
    x = 2 +
    ^
    SyntaxError: invalid syntax

    Implicit line continuation only happens if you have an unmatched '('.

    >>> x = (2 +

    ... 2
    ... )
    >>> x

    4
    Dan Bishop, Jun 5, 2008
    #2
    1. Advertising

  3. Russ P.

    Russ P. Guest

    On Jun 4, 9:01 pm, Dan Bishop <> wrote:
    > On Jun 4, 10:09 pm, "Russ P." <> wrote:
    >
    > > I've always appreciated Python's lack of requirement for a semi-colon
    > > at the end of each line. I also appreciate its rules for automatic
    > > line continuation. If a statement ends with a "+", for example, Python
    > > recognizes that the statement obviously must continue.

    >
    > > I've noticed, however, that the same rule does not apply when a line
    > > ends with "and," "or," or "not." Yes, it's a minor point, but
    > > shouldn't the same rule apply?

    >
    > > Seems like it would be easy to add.

    >
    > Huh? This doesn't work either:
    >
    > >>> x = 2 +

    >
    > File "<stdin>", line 1
    > x = 2 +
    > ^
    > SyntaxError: invalid syntax
    >
    > Implicit line continuation only happens if you have an unmatched '('.
    >
    > >>> x = (2 +

    >
    > ... 2
    > ... )>>> x
    >
    > 4


    Darnit! You're right. I've been reading up on Scala lately, and I
    guess I got confused. Well, it wouldn't be a bad idea for Python to do
    what I thought it did, *plus* what I said it ought to do.

    Scala is a nice language, by the way. Check it out when you get a
    chance (http://www.scala-lang.org). I'm thinking about switching over
    to it from Python if I can. I just wish it had default arguments and
    argument passing by keyword. Now, those are a couple of features that
    I really appreciate in Python. Oh, and I wish Scala used "and" and
    "or" rather than "&&" and "||". There's another thing Python got right.
    Russ P., Jun 5, 2008
    #3
  4. Russ P.

    Tim Roberts Guest

    Dan Bishop <> wrote:
    >On Jun 4, 10:09 pm, "Russ P." <> wrote:
    >> I've always appreciated Python's lack of requirement for a semi-colon
    >> at the end of each line. I also appreciate its rules for automatic
    >> line continuation. If a statement ends with a "+", for example, Python
    >> recognizes that the statement obviously must continue.
    >>
    >> I've noticed, however, that the same rule does not apply when a line
    >> ends with "and," "or," or "not." Yes, it's a minor point, but
    >> shouldn't the same rule apply?
    >>
    >> Seems like it would be easy to add.

    >...
    >Implicit line continuation only happens if you have an unmatched '('.
    >
    >>>> x = (2 +

    >... 2
    >... )
    >>>> x

    >4


    .... or an unmatched [ or an unmatched {.
    --
    Tim Roberts,
    Providenza & Boekelheide, Inc.
    Tim Roberts, Jun 5, 2008
    #4
  5. Russ P.

    Terry Reedy Guest

    "Russ P." <> wrote in message
    news:...
    |. Well, it wouldn't be a bad idea for Python to do
    | what I thought it did, *plus* what I said it ought to do.

    A line ending in an operator is ambiguous in that it *could* indicate that
    the programmer intends to continue on the next line while it also could
    indicate that the programmer forgot to finish before hitting return, or
    that something got erased but not replaced. Moreover, the second
    possibility is actual (it actually happens) and not just theoretical.
    Moreover, the next line realistically could 'complete' the incomplete line
    'by accident', so that the syntax bug would not get flagged.

    In such situations, some might lean toward the plausible guess choice, but
    Guido leans in the direction of choosing the bug interpretation. So he
    included the '\' mechanism. It is already used in strings to mean "do not
    take the next char literally", so having it mean "do not take the following
    end-of-line literally" is only a tiny step.

    Terry Jan Reedy
    Terry Reedy, Jun 5, 2008
    #5
  6. Russ P.

    Paul Boddie Guest

    On 5 Jun, 22:40, "Terry Reedy" <> wrote:
    >
    > A line ending in an operator is ambiguous in that it *could* indicate that
    > the programmer intends to continue on the next line while it also could
    > indicate that the programmer forgot to finish before hitting return, or
    > that something got erased but not replaced.


    Yes, this is an excellent point. For the logical operators, consider
    code like the following...

    x = obj1.something() and obj2.conditional() and # time for lunch!
    obj4.obligatory_something()

    Although a trailing "and" or "or" operator might suggest a
    continuation of the expression on the next line, one has to consider
    whether the next line (or almost any line defining an expression)
    should suggest possible membership of an expression on the preceding
    line by default for its contents. One could, of course, insist on
    indentation to prevent such ambiguity since the second line above
    shouldn't be indented further if part of a separate statement. More
    work is definitely needed on such a proposal, certainly.

    Paul
    Paul Boddie, Jun 5, 2008
    #6
    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. Sandra-24
    Replies:
    5
    Views:
    397
    Leif K-Brooks
    Apr 9, 2006
  2. Robert Dodier
    Replies:
    1
    Views:
    226
    Dan Bishop
    Jul 4, 2007
  3. Replies:
    6
    Views:
    291
    Daniel Pitts
    May 28, 2010
  4. Alf P. Steinbach

    Re: maximum continuation lines in C++

    Alf P. Steinbach, May 27, 2010, in forum: C++
    Replies:
    0
    Views:
    699
    Alf P. Steinbach
    May 27, 2010
  5. John Yeung
    Replies:
    0
    Views:
    176
    John Yeung
    Jun 21, 2011
Loading...

Share This Page