f



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.
0
Russ.Paielli (335)
6/5/2008 3:09:38 AM
comp.lang.python 77058 articles. 3 followers. Post Follow

7 Replies
374 Views

Similar Articles

[PageSpeed] 20

On Jun 4, 10:09=A0pm, "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 =3D 2 +
  File "<stdin>", line 1
    x =3D 2 +
          ^
SyntaxError: invalid syntax

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

>>> x =3D (2 +
=2E.. 2
=2E.. )
>>> x
4
0
danb_83 (421)
6/5/2008 4:01:53 AM
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.
0
Russ.Paielli (335)
6/5/2008 4:50:19 AM
Dan Bishop <danb_83@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.
>...
>Implicit line continuation only happens if you have an unmatched '('.
>
>>>> x = (2 +
>... 2
>... )
>>>> x
>4

.... or an unmatched [ or an unmatched {.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
0
timr (1409)
6/5/2008 7:17:31 AM
On Wed, 4 Jun 2008 21:50:19 -0700 (PDT), "Russ P."
<Russ.Paielli@gmail.com> declaimed 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 (... )
-- 
	Wulfraed	Dennis Lee Bieber		KD6MOG
	wlfraed@ix.netcom.com		wulfraed@bestiaria.com
		HTTP://wlfraed.home.netcom.com/
	(Bestiaria Support Staff:		web-asst@bestiaria.com)
		HTTP://www.bestiaria.com/
0
wlfraed (4596)
6/5/2008 9:17:20 AM
Dennis Lee Bieber wrote:
> On Wed, 4 Jun 2008 21:50:19 -0700 (PDT), "Russ P."
> <Russ.Paielli@gmail.com> declaimed 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
0
larry.bates (889)
6/5/2008 12:06:52 PM
"Russ P." <Russ.Paielli@gmail.com> wrote in message 
news:0d723e6d-f81b-4545-b406-fc60b20c5433@u6g2000prc.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





0
tjreedy (5459)
6/5/2008 8:40:44 PM
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
0
paul338 (1044)
6/5/2008 9:13:07 PM
Reply: