[Python-Dev] Re: PEP 292, Simpler String Substitutions

[François Pinard]

[Barry A. Warsaw]

>     FP> However, there are other contexts where the concept of a
>     FP> compound dictionary of all globals and locals would be useful.
>     FP> Maybe we could have some allvars() similar to globals() and
>     FP> locals(), and use `... % allvars()' instead of `.sub()'?  So
>     FP> this would serve both string interpolation and other avenues.

> Or maybe just make vars() do something more useful when no arguments
> are given?

I surely had the thought, but changing the meaning of an existing library
function is most probably out of question.

> In any event, allvars() or a-different-vars() is out of scope for this
> PEP.  We'd use it if it was there, but I think it needs its own PEP,
> which someone else will have to champion.

I do not see myself championing a PEP yet, I'm not sure the Python community
is soft enough for my thin skin (not so thin maybe, but I really had my share
of over-long discussions in other projects, I want some rest in these days).

On the other hand, the allvars() suggestion is right on the point in
my opinion.  It is not a stand-alone suggestion, its goal was to stress
out that `.sub()' is too far from the `%' operator, it looks like a
random addition.  The available formatting paradigms of Python, I mean,
those which are standard, should look a bit more unified, just to preserve
overall elegance.  If we want Python to stay elegant (which is the source
of comfort and pleasure, these being the main goals of using Python after
all), we have to seek elegance in each Python move.

To the risk of looking frenetic and heretic, I guess that `$' would become
more acceptable in view of the preceding paragraph, if we were introducing
an `$' operator for driving `$' substitutions, the same as the `%' operator
currently drives `%' substitutions.  I'm not asserting that this is the
direction to take, but I'm presenting this as an example of a direction
that would be a bit less shocking, and which through some unification,
could somewhat salvage the messy aspect of having two formatting characters.

Saying that PEP 292 rejects an idea because this idea would require another
PEP to be debated and accepted beforehand, and than rushing the acceptance
of PEP 292 as it stands, is probably missing the point of the discussion.
Each time such an argumentation is made, we loose vision and favour the
blossom of various Python features in random directions, which is not good
in the long term for Python self-consistency and elegance.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard