[Python-Dev] sWAPcASE Was: transform() and untransform() methods, and the codec registry

[Guido van Rossum]

On Thu, Dec 9, 2010 at 2:54 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
>
> On Dec 9, 2010, at 12:29 PM, Alexander Belopolsky wrote:
>
> The str type already has 40+ methods many of which are not well-suited
> to handle the complexities inherent in Unicode.   Rather than rushing
> in two more methods that will prove to be about as useful as
> str.swapcase(), lets consider actual use cases and come up with a
> design that will properly address them.
>
> It would make me happy if we could agree to kill or at least mortally wound
> str.swapcase().    I did some research on what it is go for and found
> that it is a vestige of an old word processor command to handle
> the case where a user accidentally left the caps lock key turned-on.
> AFAICT using Google's code search, it has nearly zero value for
> Python scripts.   It does have a cost however, the code search turned-up
> many cases where people were writing string like objects and included
> swapcase() just so they could match the built-in API.
> It's time for swapcase() to go the way of the dinosaurs.

I fully admit the mistakes I made by introducing swapcase() and a few
other weird string methods. It happened many eons ago; before they
were string methods they were functions in the "string" module.

At the same time I cannot bring up any enthusiasm for trying to kill
these off. The cost of the deprecation process is probably more than
the cost of keeping them around, if you integrate over the entire
community for t -> infinity. I don't see them as harmful. We had our
chance to kill them in Py3k, and we didn't.

-- 
--Guido van Rossum (python.org/~guido)