Building a multiline string
in [Python]
|
Prev: python via netcat
Next: YAML
From: lallous on 4 Feb 2010 06:34 Hello Maybe that's already documented, but it seems the parser accepts to build a long string w/o really using the first method: # Method1 x = "line1" + \ # cannot use comments! "line2"+ \ "line3" and instead using a list with one element like this: # Method2 x = [ "line1" # can use comments "line2" "line3" ][0] Or: # Method3 x = ( "line1" # can use comments "line2" "line3" ) (Not that I don't want new lines in the strings) Now should I be using method 2 or 3 in production code? -- Elias
From: Ulrich Eckhardt on 4 Feb 2010 07:09 Just for the record: Neither of the below methods actually produce a multiline string. They only spread a string containing one line over multiple lines of source code. lallous wrote: > Maybe that's already documented, but it seems the parser accepts to > build a long string w/o really using the first method: > > # Method1 > x = "line1" + \ # cannot use comments! > "line2"+ \ > "line3" Well, obviously you can't use comments like that there. The point of the backslash is that it continues the current logical line over the _immediately_ _following_ newline. If anything follows, that obviously doesn't work. > and instead using a list with one element like this: > > # Method2 > x = [ > "line1" # can use comments > "line2" > "line3" > ][0] This basically makes use of the fact that "this" "is" "one" "string" and not four strings. > # Method3 > x = ( > "line1" # can use comments > "line2" > "line3" > ) This uses the same, only that this time it uses brackets which cause an expression to extend to multiple lines. > (Not that I don't want new lines in the strings) You don't not want or you don't want newlines? Depending on that, you could also do this: # method 4 x = "line1"\ "line2"\ "line3" or maybe # method 5 x = """line1 line2 line3 """ > Now should I be using method 2 or 3 in production code? I'd go for 3 or 4. 2 is basically a hack (you could do the same with a dictionary, or a tuple, not only a list). 1 will actually create strings and then concatenate them (unless Python is smart enough to optimize that), but it allows adding expressions in the middle. Uli -- Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
From: Steve Holden on 4 Feb 2010 07:31 lallous wrote: > Hello > > Maybe that's already documented, but it seems the parser accepts to > build a long string w/o really using the first method: > > # Method1 > x = "line1" + \ # cannot use comments! > "line2"+ \ > "line3" > > and instead using a list with one element like this: > > # Method2 > x = [ > "line1" # can use comments > "line2" > "line3" > ][0] > > Or: > # Method3 > x = ( > "line1" # can use comments > "line2" > "line3" > ) > > (Not that I don't want new lines in the strings) > > Now should I be using method 2 or 3 in production code? > I should have thought it was pretty obvious that method 2 creates a list and then performs an indexing operation on it. These are completely unnecessary operations, which are avoided in method 3 which is a simple parenthesised expression. So why anyone would want to adopt method 2, which is also mess clear as source code, is beyond me. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/
From: Marco Mariani on 4 Feb 2010 08:23 On 02/04/2010 12:34 PM, lallous wrote: > Now should I be using method 2 or 3 in production code? Another way... depending on what you are using the string for, of course. If it's an HTML/XML/SQL/whatever piece of code: >>>> from textwrap import dedent >>>> sql = dedent(""" > ... SELECT * > ... FROM table > ... WHERE foo=bar > ... """) >>>> >>>> print sql > > SELECT * > FROM table > WHERE foo=bar > And if you don't want the starting/ending newlines: >>>> sql = dedent("""\ > ... SELECT * > ... FROM table > ... WHERE foo=bar\ > ... """) >>>> >>>> print sql > SELECT * > FROM table > WHERE foo=bar >>>> I use this sometimes to keep both python and the embedded code readable while preserving indentation.
From: Duncan Booth on 4 Feb 2010 13:23
lallous <lallous(a)lgwm.org> wrote: > Now should I be using method 2 or 3 in production code? Also Method1a: # Method1a x = ("line1" + # can use comments! "line2"+ "line3") Use Method1a or Method3 as you prefer: either of these generates a single string constant. Method2 is dumb. |