>> [tim, wondering whether don wants a newline at the end too]
> [don sez yes]
OK! Then the next step is to ask whether you _do_ a want a newline at
the start of the "this" line, and/or also want a number of spaces
following the newline at the end of the "has" line. I think the answers
are "no" to both. What I'm really trying to get at is that a scheme that
"fits" with Python's whitespace-driven syntax is tricky to come up with;
to get your example to work the way you want, we need some number of
non-obvious "un-quoting-like" rules too (like the newline after the "%("
doesn't count, although the other newlines do; and _some_ amount of
leading whitespace on every line inside the quotes doesn't count (all?
just up to & including the column position of the "(" in the opening
"%("? if the latter, is it a syntax error if lines have any non-
whitespace characters in those column postions? or what if there are two
adjacent newlines, so that there aren't any characters in those
positions? ...)). Not saying they're unsolvable, just saying it's not
obvious what to do about all that, and that's not a good sign _in_ a
language that prides itself on obvious syntax.
OTOH, _the_ most "obvious" syntax (in the sense of following Python's
existing quoting methods as closely as possible) is ugly:
big_string = %(this is a really big multi line string that
has embedded "double quotes" and 'single quotes'
%)
Despite that I'll never get python-mode to figure that out (try fancy
quoting under perl-mode sometime <wink/sigh>), I think I like that
better, for the obvious WYSIWYG reason.
>The point I was trying to make was that it would be nice if you could
>enter large amounts of text without having to escape all of your
>quotes and paste together a bunch of smaller strings.
Sure! It would be. It would be even nicer if you could interpolate
variable values too, without having to write all the fixed parts of the
text as separate strings, backtick all the variable names, and explicitly
catenate the pieces together. That kind of thing is tedious in Python.
>I certaintly was not trying to suggest adding all those perl-isms that
>you mentioned.
Well, apart from Perl's command-substitution form of "quoting" (which
really is delightfully or disgustingly over the edge, depending on who's
judging), the _functionality_ there was just what you want, plus optional
variable interpolation. Both are very handy things to have! Even
handier if numeric objects magically convert themselves to strings when
interpolated, or if objects in general magically invoke their __repr__
method.
>... But, based on your comments, I take it that you like the idea :)
I do like the _functionality_. I still don't know whether I'd like it in
Python, though; wasn't arguing pro or con before, was just showing a
relevant scheme from a different language that works very well in practice.
>>> ... And as an extra bonus, it would generate code that was much more
>>> efficient.
>> [tim sez that's weak, cuz python could collapse it at translation time]
>Ok, so the bonus is weak (assuming of course that someone bothers to
>make your suggested optimization).
Actually, it's weak even if someone doesn't <grin>.
>But, I have to wonder, do you also complain when the guy down at EggRoll
>Express gives you a free bowl of soup with your Kung Pao Chicken
>luncheon special.
Na, anything as ineffective as whining is restricted to the net. Last
time your scenario came up, I simply dumped the soup on his head <smile>.
'demurely y\'rs - ' + tims.cutesy_signature() + '\nTim Peters ' + \
'tim@ksr.com' + '\nnot speaking for ' + `employer[tims]` + '\n'