Matt Nordhoff:
> It's useful when wrapping a line. For lack of better lorem ipsum:
>
> whatever = some_function("Your mistake is caused by Python not "
> "following one of its general rules:\n\n"
> "Explicit is better than implicit.")
>
> You can also use backslashes, and probably even + if you want to, but
> the implicit concatenation is prettier (IMO, at least ;-).
Adding a + at the end of lines isn't much extra work:
whatever = some_function("Your mistake is caused by Python not " +
"following one of its general rules:\n\n" +
"Explicit is better than implicit.")
Or even:
whatever = "Your mistake is caused by Python not " + \
"following one of its general rules:\n\n" + \
"Explicit is better than implicit."
> But you do have a point. I have never thought about the problems it
> could cause.
Probably such problems aren't much common, because common bugs are
already prevented by Python designers :-) But I think once I have
written a bug like this:
parts = ["foo", "bar" "baz", "spam"]
Where I meant a list of 4 strings.
> BTW, I could easily be wrong, but I think C behaves the same way as Python.
I know, but here changing the behavior respect to C doesn't cause bugs
to C programmers, because in that situation their Python program just
doesn't run. So it's not a Python syntax that looks like a C syntax
that behaves in a different way (this rule is used by the D designer
too: when something behaves differently from C (often to avoid a
common C pitfall), it has a different syntax. Where the D syntax is
the same of C syntax, then the D behavior is generally the same. This
avoids several problems to programmers coming from C/C++).
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
