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