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

[Russ P.]

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.

[Dan Bishop]

On Jun 4, 10:09*pm, "Russ P." <[e-mail]:

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

[Russ P.]

On Jun 4, 9:01 pm, Dan Bishop <[e-mail]:

On Jun 4, 10:09 pm, "Russ P." <[e-mail]:

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.

[Tim Roberts]

Dan Bishop <da*****@yahoo.comwrote:

>On Jun 4, 10:09*pm, "Russ P." <[e-mail]:

>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, ti**@probo.com
Providenza & Boekelheide, Inc.

[Larry Bates]

Dennis Lee Bieber wrote:

On Wed, 4 Jun 2008 21:50:19 -0700 (PDT), "Russ P."
<Ru**********@gmail.comdeclaimed the following in comp.lang.python:

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

Is it that much of a difficulty to start multiline expresssions with
a (...

That already covers all the conditions you want... Or just using a
line ending of \
(which I find less appealing than the (... )

I suppose this is a matter of "taste". I find using parenthesis to trigger line
continuations undesirable. Lines ending in backslash are explicit and easy to
mentally parse.

-Larry

[Terry Reedy]

"Russ P." <Ru**********@gmail.comwrote in message
news:0d**********************************@u6g2000p rc.googlegroups.com...
|. 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

[Paul Boddie]

On 5 Jun, 22:40, "Terry Reedy" <[e-mail]:

>
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