Re: Multi-line string extension

Tim Peters (tim@ksr.com)
Wed, 20 Apr 94 15:44:24 -0400

> [steve]
> ... the dictionary ought to be an explicit argument. You might JUST as
> likely want to substitute from a special (user-created) symbol-table
> dict, as you would from the variables in the namspace __dict__.

Have nothing against explicit dicts (as a later more-detailed sketch
said). Disagree that you're "just as" likely to want them, though (based
on non-trivial experience using similar facilities in shells & Perl). Do
not want to _require_ an explicit dict, because (a) namespace dicts will
be most common, & (b) there's no reasonably pleasant way to explicitly
_say_ "a dict corresponding to my local namespace" today in Python (the
closest you can get today is "dir()", and that only returns the local
NS's dict's keys). So requiring an explicit dict would make the most
common case the (by far) hardest to write.

> BUT:
> Unless the dictionary values are all strings,

Believe a pleasant facility must automatically apply __str__ to
substituted values before substitution (e.g., note that in Don's example
he intended to substitute integer values; so his example implicitly
relied on conversions to string getting done by magic; and it _should_,
but "magic" takes some work under the covers).

> they ought to have some optional format+lenght specifiers in the
> syntax. Even if they ARE strings, it would be nice to be able to
> specify the size of the field.
> ...
> As long as we're all digging down into our wish lists, maybe someone
> can come up with a syntax scheme that will allow both numeric printf
> style format specification, and some sort of template substitution that
> preserves the column alignment between the format string and the output
> string.

I'd like all of that too, and believe Perl in particular supplies
pleasant approaches to all of that.

But I don't believe any of it needs to be *built-in* to Python. Given
(a) multi-line strings, and (b) a blessed way to capture namespace
snapshots as dicts, any conceivable formatting scheme could just as well
be implemented _in_ vanilla Python, with an ordinary functional and/or OO
interface. Play with competing schemes that way, then if someone is
worried enough about speed, they could reimplement the Universal Favorite
in C as an extension module.

looking-for-tools-not-solutions-in-the-base-language-ly y'rs - tim