> > 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4