Chris Angelico wrote:
> On Sat, Jul 30, 2011 at 4:45 AM, OKB (not okblacke)
> Suppose you want to have a lengthy piece of text embedded in your
> source code, which you will then pass to a GUI widget for display.
> You want the widget to handle word wrap, so you don't want internal
> line breaks getting in the way, but you want the source code to be
> wrapped. What's the best way to do this? I've never been a fan of
> string literals needing run-time adjustments (like stripping
> indentation from triple-quoted strings - it usually depends on the
> indent on the second line, and what if you want that second line to
> be differently indented from the others?), so to my mind the
> cleanest way would be abuttal:
>
> "Lorem ipsum dolor sit amet, consectetur "
> "adipiscing elit. Fusce fermentum posuere "
> "mi eget molestie. Nulla facilisi. Curabitur "
> "et ultrices massa."
>
> The code's indented four spaces, but I don't have to strip them
> from the string. (Depending on context, I might need to put parens
> around that to force it to be parsed as a single string. Small
> potatoes.)
Yeah, what I'm suggesting as the cleanest way is to simply make it
all one long string literal, which is wrapped by the editor to the
proper indentation point. I can't show this in a newgroup post, but
it'd be like:
def somefunc():
if someCondition():
"Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Fusce fermentum posuere mi eget molestie. Nulla facilisi. Curabitur et
ultrices massa."
. . . except that the wrapped lines of the lorem ipsum would all line up
at the same level as the open quote. This is clean because you get to
type it exactly as you wanted it. You don't need to include extraneous
whitespice to get it to line up or wrap in your editor, and you also
don't need to choose the wrap points to put in extra quotes, as in your
example. The irritating thing about doing it your way is that if you
later change the text and it rewraps, you have to move your quote marks.
> In code, though, explicit whitespace is only needed to
>> indicate semantically meaningful stuff, so you should only use it
>> for that, and the editor should insert "visual space" (without
>> actual whitespace characters in the file) to make things like up
>> at the semantic indentation levels.
>
> Interesting concept. This suggests that your source file does not
> actually have the indentation, but the display does. This is an
> interesting way of dealing with triple-quoted strings.
>
> foo = """This is line 1.
> This is line 2.
> Line 3."""
> print(foo)
>
> If that displayed indented, maybe with a faint vertical line
> showing the string's left margin, that would greatly improve
> readability. Any editor that doesn't support this feature would
> simply see it flush left, slightly ugly but workable. Very nice
> idea... but I don't feel like implementing it. :)
Right, that's the idea, although actually I don't have an editor
that goes quite that far. I use EditPadPro (and previously used
TextPad), which support this, but only for wrapping single lines of text
(i.e., without hitting enter). If you insert a hard linebreak (e.g., to
separate paragraphs), then explicit indentation is inserted in the
string. My usual solution is to insert a hard linebreak right at the
beginning, so at least all the text is indented by the same amount.
This does involve inserting extraneous whitespace, but in the least
obstrusive way possible.
The editors have to insert real whitespace on linebreak because you
need that indentation if you're linebreaking between lines of code. It
would be nice if they had Python-aware syntax fiddling that noticed that
you were hitting Enter inside a triple-quoted string, and suppressed the
whitespace characters in that situation, but the editors I use don't
currently do that.
--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown
--
http://mail.python.org/mailman/listinfo/python-list
