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.