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. cheers - chris -- 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/