So that the meaning of a string literal depends on a pragma N lines away?
Yuck <wink>.
If a language intends to support text in a pleasant way, it really needs
to let you enter text without making newlines explicit or escaping common
characters like quotes -- to let you type (or paste, or ...) in text just
the way it looks, and reformat it without hassle. Given Python's
indentation-based syntax, it would also be very helpful to further adopt
a sh-like kludge to strip a well-defined amount of whitespace from the
start of the lines of a text block.
But I don't think anything else is needed in the base language. The
ever-growing number of "formatting features" could be supplied by
functions in a format module (whether implemented in Python or C is
irrelevant to functionality), a la
textblock = """\
line1
line2
etc
"""
import format
print format.extended_sprintf(textblock, substitution_dict) # Don-style
print format.lisp_backtick(textblock, substitution_dict) # Dan-style
print format.abc_backtick(textblock, vars()) # ABC-style
print format.simple_substitute(textblock, vars()) # Tim-style
print format.template(textblock, vars()) # Perl-format-style
print format.try_everything(textblock, substitution_dict, vars(), ...) # ??
Then the features needed would be explicit at the point of use, outside
the base language, user-redefinable if they suck, and user-extendible in
any case. If people like an OO interface better, fine, they can wrap
textblocks in text objects and chain formatting methods instead.
Whatever!
BTW, the simple formatting methods would be easier to call if a callee
could find its caller's namespaces without making the caller pass them.
Seems like it's also hard to spell "my global namespace" without hard-
coding the name of the file into a "vars" invocation (the
alternative
vars(sys.modules[__name__]) # my global NS
requires a good deal more sophistication of a user than
vars() # my local NS
).
If we _have_ to build some of the _formatting_ extensions in to the base
language, I'd vote for Don/Guido's "extended sprintf", and leave it at
that. The reason is that the design of a good formatting facility is a
major undertaking, and the extended-sprintf idea just makes an already-
refined-over-years-of-use good design more pleasant. Besides, it's just
changing the "%" operator, not strings per se.
minimally y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp