+1000 On Thu, May 16, 2013 at 12:11 PM, MRAB wrote:

On 16/05/2013 19:41, Bruce Leban wrote:

...

At Chris Angelico's suggestion, starting another thread on this:

The \ line continuation does not allow comments yet statements that span multiple lines may need internal comments. Also spaces after the \ are not allowed but trailing spaces are invisible to the reader but not to the parser. If you use parenthesis for continuation then you can add comments but there are cases where parenthesis don't work, for example, before in a with statement, as well as the current discussion of using \ to make implicit string concatenation explicit. So I propose adopting this rule for trailing \ continuation:

The \ continuation character may be followed by white space and a comment. If a comment is present, there must be at least one whitespace character between the \ and the comment.

That is:

x = y + \ # comment allowed here z

with a as x, \ # comment here may be useful b as y, \ # or here c as z: \ # or here pass

x = y + # syntax error z

Two reasons for requiring a space after the backslash:

(1) make the backslash more likely to stand out visually (and we can't require a space before it)

(2) \# looks like it might be an escape sequence of some sort while I don't think \ # does, making this friendlier to readers.

You don't get escape sequences outside strings, so I'd be inclined not to insist that it be followed by a space, although it could be suggested as good style.

I'm not passionate about that detail if the rest of the proposal flies.

...

+1

______________________________**_________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/**mailman/listinfo/python-ideashttp://mail.python.org/mailman/listinfo/python-ideas

-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.

I feel like this change would only help modestly with the string concatenation issue. I just want it because... well, I've frequently wished it were there in working code that has nothing to do with string concatenation... and usually wound up using superfluous and less clear extra parentheses where continuation lines would be nicer. On Thu, May 16, 2013 at 1:58 PM, Andrew Barnert wrote:

From: Bruce Leban Sent: Thursday, May 16, 2013 11:41 AM

...

The \ continuation character may be followed by white space and a comment.

This seems clean and obvious once you learn it, and it will be easy for novices to learn, and it won't affect any existing (working) code.

So, if this is enough to solve the string concatenation problem to everyone's satisfaction without any other changes, I'm definitely +1 on it.

Otherwise, I guess +0. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.

On Thu, May 16, 2013 at 5:55 PM, Terry Jan Reedy wrote:

On 5/16/2013 2:41 PM, Bruce Leban wrote:

...

(1) make the backslash more likely to stand out visually (and we can't require a space before it)

I think it stands out better by itself at the end.

Except that it makes invisible whitespace have a magical effect. Which -- at least for me -- is the primary reason *why* \-continuation is bad. Allowing whitespace (including comments) after the line-continuation would remove that gotcha. -jJ

On 17.05.13 00:26, Greg Ewing wrote:

Terry Jan Reedy wrote:

...

In a string, \ escapes the immediate next character. This idea of \ at the *end* of a line, just before the newline character, is that it escapes the newline, *just as is does within a string*.

That's how it currently works, but that doesn't mean it's how it *should* work. Especially if it leads to counter- intuitive and less-than-useful behaviour, which IMO it does.

In between tokens, we expect whitespace to be treated flexibly, in the sense that wherever one whitespace character is allowed, we can substitute more than one. Line continuation with backslash currently breaks that expectation.

I would appreciate it very much if "\" were more intelligent. So intelligent, that I don't want to avoid it, but want to use it! So let us make it ignore white-space and allow comments, and I'll be more than happy with an ugly, but really useful back-slash ! + 9**(9**9) -- Christian Tismer :^) mailto:tismer@stackless.com Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

On 17/05/2013 01:04, Terry Jan Reedy wrote:

On 5/16/2013 6:26 PM, Greg Ewing wrote:

...

Terry Jan Reedy wrote:

...

In a string, \ escapes the immediate next character. This idea of \ at the *end* of a line, just before the newline character, is that it escapes the newline, *just as is does within a string*.

That's how it currently works, but that doesn't mean it's how it *should* work.

My point is that there is a logical consistency that makes the current behavior consistent to me.

...

Especially if it leads to counter-intuitive

To me, having the \ below escape the newline that occurs 60 characters later is 'counter-intuitive'.

a + \ # a very long comment that seems to go on and on forever

The \ where it is looks to me like a stray typo and a bug. I would be less surprised if the code below worked, so my counter-proposal is that \ escaping of newline work after comments.

...

...

...

1 + # current behavior \ SyntaxError: invalid syntax

...

...

...

1 + # proposed behavior \ 2 3

...

and less-than-useful behaviour, which IMO it does.

Useful is a different issue. My counte-proposal meets the goal of mixing comments with line-continuation.

So you want \ to have a special meaning at the end of a comment? I don't even like the current behaviour of \ at the end of a raw string literal! :-) If it _did_ have a special meaning, I would've expected it to indicate that the _comment itself_ is continued onto the next line. -1

On 05/16/2013 05:04 PM, Terry Jan Reedy wrote:

On 5/16/2013 6:26 PM, Greg Ewing wrote:

...

Terry Jan Reedy wrote:

...

In a string, \ escapes the immediate next character. This idea of \ at the *end* of a line, just before the newline character, is that it escapes the newline, *just as is does within a string*.

That's how it currently works, but that doesn't mean it's how it *should* work.

My point is that there is a logical consistency that makes the current behavior consistent to me.

...

Especially if it leads to counter-intuitive

To me, having the \ below escape the newline that occurs 60 characters later is 'counter-intuitive'.

a + \ # a very long comment that seems to go on and on forever

The \ where it is looks to me like a stray typo and a bug. I would be less surprised if the code below worked, so my counter-proposal is that \ escaping of newline work after comments.

--> 1 + # current behavior \ SyntaxError: invalid syntax

--> 1 + # proposed behavior \ 2 3

I would rather see Greg's proposal; a backslash is already semi-magical with it's escaping property, so I think it makes more sense to have a backslash be able to interrupt an expression than a comment... although, having said that, brackets allow comments in the middle... I still like Greg's color better. ;) -- ~Ethan~

I'd like it if comments and/or white space could follow the \. Trailing white space after one is always difficult to notice, and the comment after the line continuation is a compelling use-case. Together, we'll have a bit less error prone line continuation syntax. — Sent from Mailbox for iPhone On Thu, May 16, 2013 at 7:45 PM, Bruce Leban wrote:

...

To me, having the \ below escape the newline that occurs 60 characters later is 'counter-intuitive'.

a + \ # a very long comment that seems to go on and on forever

The \ where it is looks to me like a stray typo and a bug. I would be less surprised if the code below worked, so my counter-proposal is that \ escaping of newline work after comments.

...

...

...

1 + # current behavior \ SyntaxError: invalid syntax

...

...

...

1 + # proposed behavior \ 2 3

...

...

...

...

and less-than-useful behaviour, which IMO it does.

Useful is a different issue. My counte-proposal meets the goal of mixing comments with line-continuation. My objection to this is that it changes meaning of current code while my

On May 16, 2013 5:05 PM, "Terry Jan Reedy" wrote: proposal doesn't. It also changes rule that everything after # is ignored. Simple example: x = y, # \ z = 1, 2 Admittedly contrived but I spent no time trying to get a less-contrived example. --- Bruce

On 16.05.2013 20:41, Bruce Leban wrote:

At Chris Angelico's suggestion, starting another thread on this:

The \ line continuation does not allow comments yet statements that span multiple lines may need internal comments. Also spaces after the \ are not allowed but trailing spaces are invisible to the reader but not to the parser. If you use parenthesis for continuation then you can add comments but there are cases where parenthesis don't work, for example, before in a with statement, as well as the current discussion of using \ to make implicit string concatenation explicit. So I propose adopting this rule for trailing \ continuation:

The \ continuation character may be followed by white space and a comment. If a comment is present, there must be at least one whitespace character between the \ and the comment.

That is:

x = y + \ # comment allowed here z

with a as x, \ # comment here may be useful b as y, \ # or here c as z: \ # or here pass

x = y + # syntax error z

Two reasons for requiring a space after the backslash:

(1) make the backslash more likely to stand out visually (and we can't require a space before it)

(2) \# looks like it might be an escape sequence of some sort while I don't think \ # does, making this friendlier to readers.

I'm not passionate about that detail if the rest of the proposal flies.

I'm -1 on making the backslash more attractive to use :-) In most use cases, you can create much more readable code by using parenthesis, which easily allow spanning statements and expressions across multiple lines. Those read better, work better in editors (automatic indentation) and are less error prone than the backslash. If there are common use cases left which can currently not be handled by parens, I'd be +1 on fixing those. Your "with" example would be one such case, since the following currently gives a SyntaxError: with (a as x, # comment here may be useful b as y, # or here c as z): # or here pass -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 17 2013)

...

...

Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

2013-05-07: Released mxODBC Zope DA 2.1.2 ... http://egenix.com/go46 2013-05-06: Released mxODBC 3.2.3 ... http://egenix.com/go45 ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On 17/05/13 10:04, Terry Jan Reedy wrote:

To me, having the \ below escape the newline that occurs 60 characters later is 'counter-intuitive'.

a + \ # a very long comment that seems to go on and on forever

You're misreading it, in my (not-so-)humble opinion :-) The backslash should not be interpreted as an escape, since escapes are only meaningful inside string literals. It should be interpreted as an instruction to the parser, telling it to treat the next line as a continuation of the current line. Anything following the \ needs to be ignored, so the only things which are legal after the backslash should be things which would be ignored anyway, namely whitespace or comments. Putting the backslash at the end of the comment is ruled out by the requirement that # comments out everything until the end of the line. Before line continuations within brackets was introduced, I would have cared much more about this issue, but now I'm finding it hard to care. I'm only +0 on allowing comments after \ and +0.5 on allowing whitespace. -- Steven

On 5/17/2013 4:59 AM, Steven D'Aprano wrote:

On 17/05/13 10:04, Terry Jan Reedy wrote:

...

To me, having the \ below escape the newline that occurs 60 characters later is 'counter-intuitive'.

a + \ # a very long comment that seems to go on and on forever

You're misreading it, in my (not-so-)humble opinion :-) Yes, it is a rather imperious opinion ;-)

The backslash should not be interpreted as an escape, since escapes are only meaningful inside string literals.

'Escape' means 'ignore the normal meaning of the following character'. That is exactly what \<newline> means. 'Excape' had that meaning long before there were python string literals. Ditto for the use of \ as an escape character, as in relational expressions. Relational expressions are typically not quoted, and the fact that they are in Python code, to first turn them into string objects rather than pattern objects, is a nuisance that lead to the r prefix hack. Do you really think Guido just coincidentally choose \ to escape newline, ignorant of its two decade history in unix? Anyway, this is all moot unless the syntax is changed in a way that forces a different interpretation. I don't think that is needed. Terry

On Fri, May 17, 2013 at 1:06 PM, Terry Jan Reedy wrote:

'Escape' means 'ignore the normal meaning of the following character'.

\ is not only an escape character as you define it. Sometimes it means the exact opposite of that: the following character has special meaning, e.g., \n \t etc. And it is also not the case that \ only applies to the single following character. \123 is a four-character escape sequence, \u1234 is a six-character sequence and \U12345678 is a ten-character sequence! (And Python is not the only language that recognizes long escape sequences.) So in this case, while the current escape sequence is \<newline>, the new proposed one is \<whitespace-other-than-newline>*[#<anything-but-newline>*]<newline> Or writing this in the style used in the python docs: "\" *whitespace**-other-than-newline* * [ "#" *anything-but-newline* * ] * newline* I understand if you disagree with the proposal. But I don't think an argument that it is fundamentally ill-defined and ignorant of history is valid. --- Bruce Latest blog post: Alice's Puzzle Page http://www.vroospeak.com Learn how hackers think: http://j.mp/gruyere-security