On 16.05.13 18:57, Christian Tismer wrote:
On 16.05.13 18:23, MRAB wrote:
On 16/05/2013 16:57, Andrew Barnert wrote:
On May 16, 2013, at 8:00, MRAB <python@mrabarnett.plus.com> wrote:
On 16/05/2013 15:44, Chris Angelico wrote:
On Fri, May 17, 2013 at 12:40 AM, MRAB <python@mrabarnett.plus.com> wrote:
On 16/05/2013 08:08, Serhiy Storchaka wrote: > As was said before the '+' operator has less priority than > the '%' operator and an attribute access, i.e. it requires > parenthesis in some cases. However parenthesis introduce a > noise and can cause other types of errors. I wonder whether we could use ".". Or would that be too confusing?
And I apologized for borrowing an idea from bash. Taking an idea from PHP?!? It has high precendence as far as the parser is concerned.
I know that Perl uses it. I haven't looked at PHP (I hear bad things about it! :-)).
Seriously, I don't think another operator is needed. If it's not going to be the implicit concatenation by abuttal, + or \ will carry the matter. But I share the opinion of several here: implicit concatenation is not as bad as the alternatives. It wouldn't be an operator as such
Of course in php, perl, and every other language that uses dot for string concatenation, it _is_ an operator, so this will end up confusing the very people who initially find it comforting.
And this means the parser has to figure out whether you mean dot for attribute access or dot for concatenation. That's not exactly a _hard_ problem, but it's not _trivial_.
And then there's the fact that the "precedence" is different depending on which meaning the dot gets. Remember that what you're trying to solve is the problem that member-dot and % both have higher precedence than +.
I thought the problem we were trying to solve was that "+" has a lower precedence than "%" and attribute/method access, so implicit concatenation that's followed by "%" or ".format" can't be replaced by "+" without adding extra parentheses.
I think the "." is a nice idea at first sight, but might become confusing in the end because what we actually need is a simple to use notation for the scanner/parser that denotes a continuation line, and _not_ an operator.
Now, what about this?
long_line = "the beginning and the"& # comments are ok " continuation of a string"
The "&" is not a valid operator on strings and looks pretty much like gluing parts together. It is better than the "\" that just escapes the newline and cannot take comments. I would even enforce that the ampersand be on the same line.
'a bitwise or :-?'& ' why not ...' in php the dot (.) is so abundantly used for staying within the line width limits, I often also insert it instead of a plus (+) when switching to python and the other way around. All the best, Stefan