Re: Multi-line string extension

Jim Roskind (jar@infoseek.com)
Sun, 17 Apr 1994 11:52:08 +0800

> Date: Sun, 17 Apr 94 03:31:24 -0400
> From: Tim Peters <tim@ksr.com>
> Sender: python-list-request@cwi.nl
>
> > [jim & john discuss the merits of extending the language to say
> > that adjacent string literals must be catenated at translation time, a
> > la ANSI-ISO C]
>
> If Python really needs this (let's see the profiling data demonstrating
> that run-time catenation of string literals is actually a bottleneck
> <wink>),

Oh, the joy of having having folks try to use my words 'gainst me ;-).

I would argue that my proposal would allow for more readable code,
without introducing additional run time operations. When your realize
how critical the "global" keyword is to performance (until your new
optimization is suggested), you quickly realize that individual
operations that induce invocation extraneous high level operations are
*bad*. The compile time concatenation of string literals is
comparable to compile time evaluation of integer constant expressions:
It is a cheap optimization, and allows for clear code to be written
with *no* potential for additional run time cost. High level
languages (such as Python) should IHMO mask (to the extent possible)
considerations of hand optimizing code, in favor quickly writing
readable code. The compile time evaluation of such constant
expressions is just one more case where coders should not have a
moments hesitation about whether a string sits in a high-frequency
loop, and hence how best to hand optimize its statement (vs. leave it
in a readable form). I'd put this enhancement in the no-brainer
category of useful (but certainly not critical) optimizations.

> One possibility we haven't discussed is "just" to liberalize Python's
> current quoted strings, so that they can slobber over multiple lines,
> sucking up any newlines embedded in them.
>
> So, e.g.,
>
> print "a long string that
> spans three lines, and
> this is the third"
>
> would print the unsurprising
>
> a long string that
> spans three lines, and
> this is the third

Hmmm... I thought you (Tim) had effectively discarded such ideas with
your criticism of the original proposal. To review what I *thought*
you had identified, and what I referred to as the [continuation of an
open string across many lines] as being antithetical to the "Python
indentation model", I'd cite the following code fragment (with
indentation rearing its head):

Your example becomes:

def main():
print "a long string that
spans three lines, and
this is the third"

Alas, *I'm* not sure what the "unsurprising result" of this print
would be. It might be:

a long string that
spans three lines, and
this is the third

or maybe it really is:

a long string that
spans three lines, and
this is the third

In fact, I would rather have enjoyed entering the original program as:

def main():
print "a long string that
spans three lines, and
this is the third"

and so my questions might be even greater. If I grant you that the
above program prints:

a long string that
spans three lines, and
this is the third

(which is one reasonable possibility, amongst the surprising choices),
then I would be left to wonder what I should write when I *really*
want to print out:

a long string that
spans three lines, and
this is the third

'cause I happen to like continuations of messages to be indented ;-).
I think the answer to such a question will certainly leave me
surprised!

The alternatives that I proposed do not seem to suffer from this
"surprising result" syndrome, 'cause they just about (or actually)
don't change the language.

> cleverly-getting-the-digraphs-out-of-don's-idea-so-it-has-a-chance-of-
> sneaking-past-guido's-robo-censor<wink>-ly y'rs - tim

...but sometimes digraphs are not the problematic element of a proposal ;-).

Jim

Jim Roskind
408-982-4469
jar@infoseek.com