[Python-Dev] PEP 292 for Python 2.4

[Brett C.]

Barry Warsaw wrote:
> 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.
> 

Ah, that's why.  Perhaps we can denote this fact in the final docs if 
the name is kept?  I personally have no issue with it now that I know 
what they stand for.  +0.

> 
[SNIP]
> 
> 
>>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).
> 

It all sounds good to me.  Unless str is going to be renamed 'string' in 
Python 3, sticking with 'string' seems fine (but then, as Barry said, we 
discussed this at PyCON so I have supported it for a while  =).  I know 
Guido suggested 'strings', and short of 'strtools', 'string' is the only 
other reasonable name to me.  Tacking on 'lib' to every package will 
become rather tedious quickly, especially when the stdlib is reorganized 
in 3.0 .

And Barry's factoring out stuff that can stand to go away also works for 
me.  Making things we don't want people to use a little harder to reach, 
but still easily accessible in the docs seems like a good solution.

+1

-Brett