On Tue, 2004-06-15 at 17:10, Raymond Hettinger wrote: > 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. > 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, although sorry Tim, I'll reject 'hamstring' outright. > > Brett and I (I forget who else was there for this) talked about where > to > > situate the PEP 292 support. The interesting idea came up to turn the > > string module into a package > . Here's the point: we know that some of the names in the current string module will always be useful. I'd hate to see us have to come up with some contrived new module for things like string.letters to live in (e.g. 'stringlib' would suck). 'string' seems like such a useful name to keep as a place to collect future useful string-related constants, utilities, and functionality, of which PEP 292 support is perhaps just the first example. I'd be perfectly happy splitting string.py into two parts after moving it into Lib/string. One would be named 'deprecated.py' and that would contain all the someday-to-be-deleted functions. The other might be called 'constants.py' for lack of a better name, and would contain things we know we want to keep, like letters, hexdigits, etc. string/__init__.py can hide all that and it would be a simple matter once we ever decide to actually remove the deprecated functions <wink> to do it in two steps (strawman: remove the 'from deprecated import *' from Lib/string/__init__.py but leave the module around for diehards, then eventually remove the module). 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). > 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. > 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 only complication in the implementation is the cache of the converted-to-%s string in the subclass, but this is critical. In an i18n application you need the original string for catalog lookup, and the transformed string is only useful for the mod operation. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url :