On 05/17/2013 06:41 AM, Steven D'Aprano wrote:
On 17/05/13 19:32, Christian Tismer wrote:
On 16.05.13 20:20, Chris Angelico wrote:
On Fri, May 17, 2013 at 4:14 AM, Bruce Leban <bruce@leapyear.org> wrote:
I'm not passionate about that detail if the rest of the proposal flies.
Spin that off as a separate thread, I think the change to the backslash rules stands alone. I would support it; allowing a line-continuation backslash to be followed by a comment is a Good Thing imo.
I don't think these matters should be discussed in separate threads.
They clearly should be in different threads. Line continuation is orthogonal to string continuation. You can have string concatenation on a single line:
s = "Label:\t" r"Data containing \ backslashes"
Can you think of, or find an example of two adjacent strings on the same line that can't be written as a single string? s = "Label:\t Data containing \ backslashes" I'm curious about how much of a problem not having implicit string concatenations really is?
And you can have line continuations not involving strings:
result = math.sin(23*theta) + cos(17*theta) - \ sin(3*theta**2)*cos(5*theta**3)
Since the two things under discussion are independent, they should be discussed in different threads.
- implicit string concatenation becomes deprecated
-1
Implicit string concatenation is useful, and used by many people without problems.
This is why they are trying to find an explicit alternative.
- the backslash will allow comments, as proposed by Bruce
+0
It's not really that important these days. If you want comments, use brackets to group a multi-line expression.
- continuation of a string on the next line will later enforce the backslash.
I don't understand what this sentence means.
So repeating Bruce's example, the following would be allowed:
x = [ # THIS WOULD BE ALLOWED 'abc' \ 'def' \ # not the python keyword 'ghi' ]
The backslashes are redundant, since the square brackets already enable a multi-line expression.
But it is also a source of errors which appears to happen often enough, or is annoying enough, to be worth changing. Guido's example was a situation where a comma was left out and two strings were joined inside a list without an error message. If you accidentally put a comma in a multi line expression inside parentheses, it becomes a tuple without an error message.
('abc' ... 'def', ... 'ghi') ('abcdef', 'ghi')
By removing implicit string concatenations, an error can be raised in some of these situations. The fact that these errors are silent and may not be noticed until a programs actually used is an important part of this. Or even worse, not noticed at all!
'\' would become kind of a line glue operator that becomes needed to merge the strings.
-1 since there are uses for concatenating strings on a single line.
Guido's suggestion is just to live with using a '+'. His point was that any extra overhead wouldn't be that harmful as literal string concatenations tend to be in initiation parts of programs. But the + has a lower precedence than %. Which is inconvenient.
I don't think that parentheses are superior for that. Parentheses are for expressions and they suggest expressions. Avoiding parentheses where they don't group parts of expressions is imo a good thing.
I agree with this. Especially if the expression being grouped has parentheses inside it.
I don't understand this objection, since the parentheses are being used to group an expression. And they are being used to group expressions.
It's also a matter of reducing errors. I think it improves readability as well. Which also reduces errors.
The reason why Python has grown the recommendation to use parentheses comes more from the absence of a good alternative.
Maybe so, but now that we have multi-line expressions inside brackets, the need for an alternative is much reduced.
If you use braces, you get a one item list as the result. Parentheses are used to change an expressions order of evaluation as well. Ron