[Patches] string.translate behaviour
M.-A. Lemburg
mal@lemburg.com
Mon, 29 May 2000 09:32:43 +0200
> Problem:
> The string.translate() function has an unpleasant interface, requiring a
> 256-character string containing a translation table.
> string.maketrans() was subsequently added as a helper function to make
> the job easier, but string.translate() should really have an
> interface like maketrans: (fromchars, tochars [, deletechars])
> AMK says: I later proposed a solution that would let us keep
> string.translate, and would behave naturally, yet doesn't seem likely to
> break any code. string.translate would have a signature (fromchars,
> tochars [, deletechars]). If len(fromchars)!=256, it must be the
> new style; otherwise it must be the old style. The only ambiguous is if
> len(fromchars)==len(tochars)==256; is it a new-style call
> that's doing a complete permutation, or is it an old-style call with a
> 256-char list of characters to delete. Case II seems unlikely to
> occur in practice, so we'll assume case I and resolve the ambiguity that
> way.
> AMK will implement this one spare weekend.
> Edit this entry / Log info / Last changed on Wed Jul 22 09:26:56 1998 by
> A.M. Kuchling
>
> Solution:
> I still think this is a good idea and so I have implemented
> this behaviour. It does not make the code cleaner, but it's sure
> a nice feature to have.
Note that Unicode uses a new approach here (which I find much
more useful, BTW):
"""
S.translate(table) -> unicode
Return a copy of the string S, where all characters have been mapped
through the given translation table, which must be a mapping of
Unicode ordinals to Unicode ordinals or None. Unmapped characters
are left untouched. Characters mapped to None are deleted.
"""
--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/