Re: python strings

jredford@lehman.com
Mon, 25 Apr 94 11:40:53 -0400

>> If I understand the recent discussions, there's consensus on the need
>> for something along the lines of triple-quoted strings but not on much
>> else.

Something vaguely not unlike, perhaps.

>> In my private version of what will soon be released as Python, 1.0.2
>> at the cost of increasingly messy code in tokenizer.c, I've managed to
>> implement triple-quoted strings, as well as backslash-continued
>> strings and string literal concatenation as in C, and Donald Beaudry's
>> %(name)format hack and the vars() function.

The hack & function are fine.. the concatenation seems silly, the
continuation is allowed and the """ is ugly. definitely ugly.

>> Neither do I like the idea of stripping indentation from strings --
>> for consistency, this would have to check that all lines in the string
>> are indented consistently, and it would require adding backslash-space
>> and backslash-tab as escapes interpreted in string literals. However,
>> a user function could strip indentation from long string literals
>> using rather simple regular expression replacement! In the
>> adventure-game example, such a user function would probably be needed
>> anyway, in order to reformat the output paragraphs to have a
>> consistent width.

Well, I think code indentation should _always_ look like code
indentation. If 'long strings' dont look like code, dont put them
there.

>> Here's another half-baked idea: with a little more effort (minimally a
>> parentheses-counter), %(name)format could be changed into
>> %(expression)format, passing the expression to eval() with the given
>> dictionary as globals. Disadvantage: this involves parsing and
>> compiling the string on each use (unlike back-ticks which would be
>> recognized by the parser); and it needs a way to pass zero, one or two
>> dictionaries on to eval(). I'm not sure that the former will be a big
>> performance hit. The latter could be solved by being a little
>> cleverer and allowing (), (globals), or (globals, locals) as
>> right-hand-side argument to the % operator.

This is EVIL.

Now.. after all those neagtives.. My own proposal..

import sys

S $=
This is yet another example of a long string. In this
example the string begins on the line after the $=
symbol. The string ends with a line containing =$ at the
beginning of a line, with only whitespace trailing to a
newline.
=$

def show_example():
sys.stdout.write(S)

show_example()

With output:

This is yet another example of a long string. In this
example the string begins on the line after the $=
symbol. The string ends with a line containing =$ at the
beginning of a line, with only whitespace trailing to a
newline.

Definition of long strings only allowed outside of function
definitions & so forth. Assignment or usage is dereferenced at compile
time, not runtime, to get around the desire to have long strings in
function w/o a global lookup. If another module imported the above:

import example
example.S = ''
example.show_example()

This would output the original message twice. Once a module was
compiled, if one did not 'del S' in the module, or otherwise assign a
value to 'S', then the long string would be available in the global
namespace of the module, though it would act like a normal string.

What I am basically proposing is a syntax, and a optimization with a
simple side effect.

If you wanted to avoid the side-effect and optimization, you could:

S $=
A short string or a long string.
=$

S = S

def show_example():
sys.stdout.write(S)

Here, the runtime value of S would be used.

The basic goal is to keep ugly strings out of the code...

If you really like triple quotes (ick ick ick), then gimme a
compile-time dereference operator. Heck.. give us one anyway. I'd like
to be able to know that my modules are using the values in their
globals that I put there, rather than modified ones.

i = 5

def f():
print *i

i = 6
f

produces '5'

--
John Redford (AKA GArrow) | 3,600 hours of tape.
jredford@lehman.com       | 5 cans of Scotchguard.