[Python-Dev] *Simpler* string substitutions

[Alex Martelli]

On Thursday 20 June 2002 11:21 pm, Guido van Rossum wrote:
	...
> Now back to $ vs. %.  I think I can defend having both in the
> language, but only if % is reduced to the positional version (classic
> printf).  This would be used mostly to format numerical data with
> fixed column width.  There would be very little overlap in use cases:

I think you're right: in a "greenfield" language design (a hypothetical one 
starting from scratch with no constraints of backwards compatibility) you can 
indeed defend using both % and $ for these two tasks, net of the issues of
what feature set to give $ formatting -- implicit vs nonimplicit access to
variables, including the very delicate case of access to free variables (HOW
to give access to free variables if the formatstring isn't a literal?); 
ability to use expressions and not just identifiers; ability to pass a 
mapping; what format control should be allowed in $ formatting -- and 
what syntax to use to give acces to those features.

If %(name)s is to be deprecated moving towards Python-3000 (surely it
can't be _removed_ before then), $-formatting needs a very rich feature set; 
otherwise it can't _replace_ %-formatting.  It seems to me that (assuming
$ formatting IS destined to get into Python) $ formatting should then be
introduced with all or most of the formatting power it eventually needs, so
that those who want to make their programs Py3K-ready can use $ formatting
to replace all their uses of %(name)s formatting.

The "transition" period will thus inevitably offer different ways to perform 
the same tasks -- we can never get out of this bind, any time we move to
deprecate an "old way" to perform a task, since the old way and the new
way MUST both work together for a good while to allow migration.  This
substantial cost is of course worth paying only if the new way is a huge win
over the old one -- not just "somewhat" better, but ENORMOUSLY better.
But that's OK, and exactly the kind of delicate trade-off which you DO have
such a good track record at getting right in the past:-).


> All options are still open.

Thanks for clarifying this.  To me personally it seems that the gain of 
introducing $ formatting, if gain it be, is small enough not to be worth the
transition cost, but that's just opinion, hard to back up with any substance.

So I offer a real-life anecdote instead.  A colleague at Strakt (a wizard at
various communication and storage programming issues) had no previous
exposure to Python at all, his recent background being mostly with Plan-9,
Inferno, and Limbo (previously, other Bell Labs technologies, centered on
Unix and C).  He picked up Python on the job over the last few months --
basically from Python's own docs, our existing code base, and discussions
with colleagues, me included -- and didn't take long to become productive
with it.  He still has some issues.  Some are very understandable considering
his background -- e.g., he's still not fully _comfortable_ with dynamic 
typing (I predict he'll grow to like it, but Rome wasn't built in one day). 
Overall, what I would call a pretty good scenario and an implicit tribute to 
Python's simplicity / ease / power.  He may pine for Limbo, but in fact 
produces a lot of excellent Python code day in day out.

But his biggest remaining "general peeve" struck me hard the other day, 
exactly because that's not something he "heard", but an observation he
came up with all by himself, by reasonably unbiased examination of "Python as 
she's spoken".  "I wouldn't mind Python so much" (I'm paraphrasing, but that 
IS the kind of grudging-compliment understatement he did use:-) "except that 
there's always so MANY deuced ways to do everything -- can't they just pick
one and STICK with it?!".  In the widespread subtext of most Python discourse
this might sound like irony, but in his case, it was just an issue of fact 
(compared, remember, with SMALL languages such as Limbo -- bloated
ones such as, e.g., C++, are totally *outside* his purvey and experience) -- a
bewildering array of possible variations.  Surely inevitable when viewed 
diachronically (==as an evolution over time), but his view, like that of 
anybody who comes to Python anew today, is synchronic (==a snapshot at one 
moment).

I don't think there's anything we can do to AVOID this phenomenon, of course,
but right now I'm probably over-sensitized to the "transition costs" of 
introducing "yet one more way to do it" by this recent episode.  So, it 
appears to me that REDUCING the occurrence of such perceptions is important.


Alex