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

Guido van Rossum guido at python.org
Fri Dec 10 01:59:11 CET 2010

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)

More information about the Python-Dev mailing list