[Python-Dev] UserString

[Alex Martelli]

On 2005 Feb 20, at 05:20, Raymond Hettinger wrote:
    ...
> This sort of thing is easy to test for and easy to fix.  The question 
> is
> whether we care about updating this module anymore or is it a relic.
> Also, is the use case one that we care about.  AFAICT, this has never
> come up before.

I did have some issues w/UserString at a client's, but that was 
connected to some code doing type-checking (and was fixed by injecting 
basestring as a base of the client's subclass of UserString and 
ensuring the type-checking always used isinstance and basestring).

My two cents: a *mixin* to make it easy to emulate full-fledged strings 
would be almost as precious as your DictMixin (ones to emulate lists, 
sets, files [w/buffering], ..., might be even more useful).  The point 
is all of these rich interfaces have a lot of redundancy and a mixin 
can provide all methods generically based on a few fundamental methods, 
which can be quite useful, just like DictMixin.

But a complete emulation of strings (etc) is mostly of "didactical" 
use, a sort of checklist to help ensure one implements all methods, not 
really useful for new code "in production"; at least, I haven't found 
such uses recently.  The above-mentioned client's class was an attempt 
to join RE functionality to strings and was a rather messy hack anyway, 
for example (perhaps prompted by client's previous familiarity with 
Perl, I'm not sure); at any rate, the client should probably have 
subclassed str or unicode if he really wanted that hack.  I can't think 
of a GOOD use for UserString (etc) since subclassing str (etc) was 
allowed in 2.2 or at least since a few loose ends about newstyle 
classes were neatly tied up in 2.3.

If we do decide "it is a relic, no more updates" perhaps some 
indication of deprecation would be warranted.  ((In any case, I do 
think the mixins would be useful)).


Alex