aleax at aleax.it
Sun Feb 20 09:32:35 CET 2005
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
> 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)).
More information about the Python-Dev