«

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.

On Jun 4, 10:09*pm, "Russ P." <Russ.Paie...@gmail.com> 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

On Jun 4, 9:01 pm, Dan Bishop <danb...@yahoo.com> wrote:
> On Jun 4, 10:09 pm, "Russ P." <Russ.Paie...@gmail.com> 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.

Dan Bishop <> wrote:
>On Jun 4, 10:09*pm, "Russ P." <Russ.Paie...@gmail.com> 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.

"Russ P." <> wrote in message
news:0d723e6d-f81b-4545-b406-...
|. 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

On 5 Jun, 22:40, "Terry Reedy" <tjre...@udel.edu> 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