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
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
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/
> 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.
> 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.
On Feb 4, 1:09 pm, Ulrich Eckhardt <eckha...@satorlaser.com> wrote:
> 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.
>
I meant:
"Note" -> "Note: I don't want to use new lines"
I did not want a multi line string
Thanks guys, method 3 seems to be good enough.
You should indent the second and following lines (I changed the name to
"xyz" to make clear that the following lines use a regular Python indent
rather than lining up under the open paren):
xyz = (
"line1" # can use comments
"line2"
"line3"
)
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
import antigravity