[Python-Dev] PEP 292 for Python 2.4

[Raymond Hettinger]

> > For completeness, perhaps update the PEP to specify what will happen
> > with $ strings that do not fall under $$, $indentifier, or
> > ${identifier}.
> 
> Good point, I've pushed out an update.

Thanks.


 
> > The names dstring(), astring(), safedict(), and nsdict() could
likely be
> > improved to be more suggestive of what they do.
> 
> The 'd' is a mnemonic for 'dollar strings'.  Similarly 'a' is for
> 'attribute path'.  'safedict' is meant to imply that it will not throw
> KeyError exceptions, and 'nsdict' indicates that namespace lookups are
> used.  I'm certainly open to alternative suggestions

Since this is in a string module, the "string" part of the name can be
more abbreviated and the qualifier should be less abbreviated.

dstring:    dollarstr, formatstr, dollarfmt, template, kwdonly
astring:    attrstr, attrlookup, dottedfmt, kwdattr
safedict:   defaultdict, 
nsdict:     nslookup, namespace, envdict

Cheetah has been through several versions.  Perhaps, they have worked
out some better naming conventions.



> I don't think documentation is a problem.  I'd propose (and would even
> write) splitting the current string module so that the deprecated
> functions are described in a subsection that doesn't appear on the
main
> module page.  That way, the documentation just describes the constants
> we want to keep and the new PEP 292 support (perhaps in another new
> subsection).

That's reasonable.  A string module is the natural place to locate the
simplified substitutions.  Splitting out the old functions seems like a
good way to re-use the string module without breathing life into things
that I was hoping that people would forget ever existed (otherwise, we
will never be rid of them).

Please do give consideration to putting all of this in a single module.
IMO, this is too small of an addition to warrant splitting everything in
to packages (which make it more difficult to understand and maintain as
a collective unit).



> > Can safedict.safedict() be made more general so that it has value
> > outside of string substitutions.
> 
> It's such a trivial matter to subclass from dict and write your own
> __getitem__() that I doubt it's worth it.

True enough.  Do consider having an optional argument for setting the
default string.  Ideally, the class should be useful with both $
formatted and % formatted strings (for instance, make it return the key
unchanged when the key is not found).  Also, since the implementation is
so tightly bound to $ formatting, it makes no sense to put it in a
separate module.



> > Given the simplicity of the PEP, the sandbox implementation is
> > surprisingly intricate.  Is it possible to simplify it with a
function
> > based rather than class based approach?
> 
> Take away all the comments, and it's really a fairly simple
> implementation.  I really want to use traditional % syntax to perform
> the substitutions since that's the Pythonically natural way to spell
> string interpolation. 

The overall goal of the PEP is simplification.  It takes very little
complexity before $ formatting becomes more complicated than %
formatting.

The % syntax has its share of issues (hard to find in the docs;
precedence is more appropriate for integer modulo; tuple vs single
string argument).

If you give up the % syntax, you get perfectly pythonic method calls and
an opportunity to do the whole job with only one exposed,
differentiating the approaches with various method names:

t = Template('$who owes me ${what')
t.subst_from_dict(mydict)
t.subst_from_env()
t.subst_from_attr()
t.subst(mydict, noexception=True)


Something like this would mean that you don't need several different
classes to do the job.  Also, compare the following for obviousness and
readability:

Template('$name loves $spouse').subst(mydict, noexception=True)
dstring('$name loves $spouse') % SafeDict(mydict)



>  In an i18n application you need the original string for
> catalog lookup, and the transformed string is only useful for the mod
> operation.

That settles that one.



Raymond