[Patches] string.translate behaviour

[Moshe Zadka]

On Sun, 28 May 2000, Peter Schneider-Kamp wrote:

> 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.

It looks way, way too DWIM for my tastes. Wouldn't it be better to have a function with a brand new name which works correctly without guessing?
--
Moshe Zadka <moshez@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com