views:

274

answers:

4

In python 2.6, why is the following line valid?

my_line = 'foo' 'bar'

and if that is valid, why isn't the following:

my_list = 1 2

The first example is string concatenation, however, the following isn't valid either (thanks god):

foo = 'foo'
bar = 'bar'
foo_bar = foo bar
+8  A: 

my_line = 'foo' 'bar' is string concatenation.

jldupont
Still works in Python 3.1 but I dislike it very much.
Hamish Grubijan
@Ipthnc me too. Luckily I haven't come across code written this way, and I hope I never have to... I'm sure I'll forget what the heck it means!
TM
It might be useful when "auto-generating" code but aside from this, I fail to see the advantage (if any).
jldupont
C and C++ do this too. I don't know of any really good reason for Python to have the same quirk. In this particular case, `'foo' + 'bar'` compiles to exactly the same bytecode, but IIRC the bytecode compiler does not *always* constant-fold string addition.
Jason Orendorff
This basically looks like an operation is done (string concat) without the use of any operator or function. I know this is valid Python, but cannot imagine why anyone would want this, let alone have it work on types other than strings.
MAK
When generating Python code programmatically, issuing the the fragment `"fragment1"` semi-independently from another fragment `"fragment"` on the same line is easier than having to track another state in an FSM to account for open-close string literal.
jldupont
@Jason, I believe that's false, as this is done at compilation time, not run time. See my answers for a link that shows good reasons for having this feature.
Peter Hansen
It's so you can break up strings across multiple lines. You can do something like `my_str = ('A really long string that's hard to fit on a line ' \n 'combined with another really long string on another line.'`) (Can't do proper formatting in comments, but imagine that spans two lines.) It's actually pretty useful and fairly common in Python source code. For what it's worth, C/C++ allow the same sort of automatic string concatenation.
mipadi
What about using docstrings then, instead of this trick?
jldupont
@jldupont, one down-side of triple-quoted strings is that they include whitespace from any indentation. That would often force you to left-align everything in them, which can often break up the "flow" of code for the reader. I use triple-quoted strings for multiline constants, defined outside of classes or functions, but inside either I usually prefer the string concatentation approach.
Peter Hansen
@Peter Hansen: that makes sense. I remember using docstrings in unconventional ways in the past and I had to do "editing on-the-fly" but chose docstring anyways because they are easier to read. I guess there are many ways to skin a cat.
jldupont
+16  A: 

This is doing string literal concatenation. As noted in the documentation, advantages include the following:

This feature can be used to reduce the number of backslashes needed, to split long strings conveniently across long lines, or even to add comments to parts of strings...

It goes on to note that this concatenation is done at compilation time rather than run time.

The history and rationale behind this, and a rejected suggestion to remove the feature, is described in PEP 3126.

Peter Hansen
+5  A: 

It isn't inconsistent. Strings and integers have different methods.

Integer concatenation is meaningless.

String concatenation is a meaningful default behavior.

S.Lott
+5  A: 

Perhaps this is of C's ancestry. In C, the following is perfectly valid:

char* ptr = "hello " "world";

It is implemented by the C pre-processor (cpp), and the rationale given in that link is:

this allows long strings to be split over multiple lines, and also allows string literals resulting from C preprocessor defines and macros to be appended to strings at compile time

Eli Bendersky