[Python-Dev] Maintenance burden of str.swapcase

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