[Python-Dev] PEP 292 for Python 2.4

[Barry Warsaw]

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

> -1

:(

> The inclusion of string.py breathes life into something that needs to
> disappear.  One of the reasons for deprecating these functions is to
> reduce the number of things you need to learn and remember.
> Interspersing a handful of new functions and classes is contrary to that
> goal.  It becomes hard to introduce simplified substitutions without
> talking about all the other string functions that you're better off not
> knowing about.
> 
> A separate module is preferable.  Also, I don't see any benefit into
> rolling a package with safedict and nsdict in a separate module from
> dstring and astring.

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 : http://mail.python.org/pipermail/python-dev/attachments/20040616/2f132fa6/attachment.bin