On Wed, Sep 7, 2011 at 7:23 AM, Raymond Hettinger <raymond.hettin...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com