[Python-Dev] PEP 292, Simpler String Substitutions

[Alex Martelli]

On Thursday 20 June 2002 01:52 pm, Christian Tismer wrote:
	...
> I'd like to express my opinion at this place (which is as good
> as any other place in such a much-too-fast growing thread):

Ditto (particularly since Christian's opinions strike me as
quite sensible here).


> The following statements are ordered by increasing hate.
> 1 - I do hate the idea of introducing a "$" sign at all.

In my case, I detest the idea of using '$' for something
that is similar but subtly different from the job of '%'.  It
reeks of "more than one way to do it".  I can just picture
myself once more having to teach/explain "this, dear bright
Python beginner, is the % way of formatting, with which 
you can do tasks X, Y, Z.  However, for tasks Y, most of Z,
and a good deal of T, there is also the $ way.  It's close 
enough to the % way that you're sure to confuse their 
syntactic details when you try to learn both, but don't 
worry, those differences are arbitrary and bereft of any
mnemonic value, so your eventual confusion is totally inevitable
and you may as well give up.  Cheer up, though -- if you're
well-learned in C (not Java, C#, or C++, but the Real
McCoy) *AND* sh (or bash or perl, and able to keep in
mind exactly what subset of their interpolation syntax
is implemented here), then you can toss a coin each and
every time you want to format/interpolate, given the wide
but not total overlap of tasks best accomplished each way.

There, aren't you happy you've chosen to learn a language
so powerful, simple, regular, and uniform, based on the self
evident principle that there should be one way, and ideally
just one way, to perform each task?"

> 2 - giving "$" special meaning in strings via a module
> 3 - doing it as a builtin function

I agree that having it as a builtin (or string method) would
be even worse than having it as a module.  A module I can
more easily try to "sweep under the carpet" as a side-show
aberration.  Built-in functions, operators, and methods of
built-in object types, are far harder to explain away.

> 4 - allowing it to address local/global variables

Yeah, I can see this smells, too, but IMHO not quite as
bad as the $-formatting - vs - %-formatting task overlap.


> Version 4 as worst comes visually quite close to
> languages like Perl. In another post, Guido answered
> such objection with "grow up". While my emotional
> reaction would be to reply with "wake up!", I have some
> rationale reasons why I don't like this:
>
> I have to read and sometimes write lots of Perl code.
> The massive use of "$" gives me true headache. I don't
> want Python to remind me of headaches.

I don't get this specific point.  As punctuation goes, $ or
% are much of a muchness from my POV (I admit to not
having a very high visual orientation, so I may be missing
some subtle point of graphical rendition?).  A massive use
of one OR the other would be just as bad.  Am I misreading
you or just missing something important?


> One argument was that "$" and the unembraced usage in "$name"
> is so common and therefore easy to sell to Python newbies.

Newbies who come from Windows and have never knowingly used a 
Unix-ish box (probably more numerous today, despite Linux's 
renaissance -- newbies do tend to grow on Microsoft operating
systems, that's what comes bundled with typical PCs today) might
of course be familiar with %name and not $name (%name is what
Microsoft's pitifully weak .BAT "language" uses).  It seems to me
that this "familiariry" argument doesn't cut much ice either way.

Were we designing from scratch, and having to choose one punctuation
character for this purpose, I'd be pretty neutral on ground of looks and
familiarity.  A slight bias against $ because on some terminals or printers
it can come out as some OTHER currency symbol, depending on various
settings, but that's pretty marginal.

But I'd much rather not have both $ and % used in slightly different
contexts for somewhat-similar, overlapping tasks...

> Fine, but no reason to adopt this overly abused character.
> Instead, I'm happy that exactly "$" is nowhere used in
> formatting.

Me, I'm happy (so far) that not BOTH $ and % are used for this,
but just one of them.

> I don't want to make Python similar to something, but to
> keep it different in this aspect. Like the triple quotes,
> the percent formatting exists rather seldom in other
> languages, and I love to use templates for makefiles,
> scripts and whatsoever, where I don't have to care too
> much about escaping the escapes.

Good point -- sometimes being different than most others has
pluses:-).  Of course, if you were templating to MS .BAT files
it would be the other way 'round, but one doesn't do that much:-).

> With an upcoming "$" feature, I fear that "%" might get
> abandoned in some future, and I loose this benefit.

This sounds to me like a FUD/"slippery slope" argument, even
though I'm in broad agreement with you.  I've neither heard nor
suspected anything about plans to introduce the huge code
breakage that abandoning % would entail.

Rather, my fear is exactly that we'll get BOTH approaches to
formatting, in an acute if localized outbreak of morethanonewayitis.


> I agree with any sensible extension/refinement of the "%" sign.

Sure.  The current %-formatting rules aren't perfect, far from it,
and while we must of course keep compatibility when the %
_operator_ is used, it WOULD be nice to have a function or
method that does something simpler and sensible with the
template string when called instead of the % operator.

> I disagree on using "$" for anything frequent in Python.

I'd have no inherent objection to using $ (or @ or ? -- I
think those are the three currently unused ASCII printing
characters) for other tasks that didn't overlap with %'s.

> I don't want to see variable names as placeholder inside
> of strings. Placeholders should be dictionary string keys,
> but this dictionary must be obtained explicitly.

Yes, I see your point.  It's definitely a valid one.

> I do like the allvars() proposal.

Me too BUT.  How would allvars deal with free variables?
eval is currently unable to deal with them very well:

>>> def f():
...   a=1; b=2; c=3
...   def g(x):
...     z = b
...     try: return eval(x)
...     except: return '%s unknown'%x
...   return g
...
>>> K=f()
>>> for Z in 'abc': print K(Z)
...
a unknown
2
c unknown
>>>

'b' is OK because the compiler has seen it used elsewhere
in nested function g, but 'a' and 'c' aren't.  If 'allvars' can't
deal with this problem, then it should not be named 'allvars'
but 'somevarsbutmaybenotalldepending'.


Alex