Default Secondary Prompt for Continuation Lines Python

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

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.

Jun 27 '08 #1

6 1834

On Jun 4, 10:09*pm, "Russ P." <Russ.Paie...@gmail.comwrote:

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

Jun 27 '08 #2

On Jun 4, 9:01 pm, Dan Bishop <danb...@yahoo.comwrote:

On Jun 4, 10:09 pm, "Russ P." <Russ.Paie...@gmail.comwrote:

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.

Jun 27 '08 #3

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

>On Jun 4, 10:09*pm, "Russ P." <Russ.Paie...@gmail.comwrote:

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

Jun 27 '08 #4

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

Jun 27 '08 #5

"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

Jun 27 '08 #6

On 5 Jun, 22:40, "Terry Reedy" <tjre...@udel.eduwrote:

>
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

Jun 27 '08 #7

This discussion thread is closed

Replies have been disabled for this discussion.

adamsappece.blogspot.com

Source: https://bytes.com/topic/python/answers/803098-line-continuation-lines-ending

Share this post