[Python-ideas] Implicit string literal concatenation considered harmful?

[Steven D'Aprano]

On 18/05/13 00:14, Ron Adam wrote:
>
> On 05/17/2013 06:41 AM, Steven D'Aprano wrote:
>> On 17/05/13 19:32, Christian Tismer wrote:
[...]
> Guido's example was a situation where a comma was left out and two strings were joined inside a list without an error message.


Actually, no, his error was inside a function call, and he was getting a TypeError of one too few arguments:

     [quote]
     I got a mysterious argument count error because instead of
     foo('a', 'b') I had written foo('a' 'b').
     [end quote]


> 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')


I think that in a realistic example, this sort of error is less likely than it might appear from such a trivial example. Normally you don't just create a string and do nothing with it. Here's an example from my own code:

         standardMsg = (
             "actual and expected sequences differ in length; expected %d"
             " items but found %d." % (len(expected), len(actual))
             )
         msg = self._formatMessage(msg, standardMsg)

If I were to accidentally insert an unwanted comma in the middle of the concatenation, I would find out immediately.

Python performs very little compile-time checking for you, and that's a virtue. The cost of this is that if you type something you didn't want, Python will do it for you regardless, and you won't find out until you try to use it. The solution is that when typing up repetitive code, you have to be a little more vigilant in Python than you would need to be in some other languages, because Python won't protect you from certain types of typo:

list_of_floats = [1.2345, 2.3456, 3,4567, 4.5678]

Python will not warn you that you have two ints where you expected one float. I've made this mistake, and then spent inordinate amounts of time not noticing the comma, but I still don't have much sympathy with the view that it is the responsibility of the language to protect me from this sort of typo.


[...]
> 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.


I think I have found the fatal problem with that suggestion: it rules out using concatenation in docstrings at all.

py> def test():
...     """Doc strings """ + "must be literals."
...
py> test.__doc__ is None
True


The equivalent with implicit concatenation works as expected.


[...]
>>> 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.

Just for the record, I am from Australia. Like in the UK, when we talk about "brackets", we mean *any* type of bracket, whether round, square or curly. Or as Americans may say, parentheses, brackets, braces. So when I say that we have multi-line expressions inside brackets, I'm referring to the fact that all three of ( [ and { act as explicit line continuations up to their matching closing bracket.



-- 
Steven