In article ,
lallous wrote:
>
>x = (
>"line1" # can use comments
>"line2"
>"line3"
>)
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"
lallous 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.
--
http://mail.python.
@Ulrich:
On Feb 4, 1:09 pm, Ulrich Eckhardt 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
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("""
> ... SEL
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:
>
> # Me
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 f
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
"l
