[Python-Dev] Maintenance burden of str.swapcase (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Sep 7 02:47:16 CEST 2011

On Wed, Sep 7, 2011 at 7:23 AM, Raymond Hettinger <raymond.hettinger at gmail.com> wrote:

On Sep 6, 2011, at 1:36 PM, Martin v. Löwis wrote: I think this is what people underestimate. I can't name applications either - but that doesn't mean they don't exist. Google code search is pretty good indicator that this method has near zero uptake.   If it dies, I don't think anyone will cry.

For str itself, I'm -0 on removing it - the Unicode implications mean implementation isn't completely trivial and there's at least one legitimate use case (i.e. providing, or deliberately reversing, Caps Lock style functionality).

However, a big +1 for deprecation in the case of bytes and bytearray. That's nothing to do with the maintenance burden though, it's to do with the semantic confusion between binary data and ASCII-encoded text implied by the retention of methods like upper(), lower() and swapcase().

Specifically, the methods I consider particularly problematic on that front are: 'capitalize' 'islower' 'istitle' 'isupper' 'lower' 'swapcase' 'title' 'upper'

These are all text operations, not something you do with binary data.

There are some other methods that make ASCII specific default assumptions regarding whitespace and line separators, but ASCII whitespace is often used as a delimiter in wire protocols so losing those would be genuinely annoying. I've also left out the methods for identifying ASCII letters and digits, since again, those are useful for interpreting various wire encodings. The case-related methods, though, have no place in sane wire protocol handling.

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list