While I'm at it, why not propose that for py3k that .rfind/.rindex/.rjust/.rsplit disappear, and
optional "fromright" (or equivalent) optional keyword argument?
This violates one of my design principles: don't add boolean options to an API that control the semantics in such a way that the option value is (nearly) always a constant. Instead, provide two different method names.
The motivation for this rule comes partly for performance: parameters are relatively expensive, and you shouldn't make the method test dynamically for a parameter value that is constant for the call site; and partly from readability: don't bother the reader with having to remember the full general functionality and how it is affected by the various flags; also, a Boolean positional argument is a really poor clue about its meaning, and it's easy to misremember the sense reversed.
PS. This is a special case of a stronger design principle: don't let the *type* of the return value depend on the *value* of the arguments.
PS2. As with all design principles, there are exceptions. But they are, um, exceptional. index/rindex is not such an exception.
FWIW, after this is over, I'll put together a draft list of these principles. The one listed above has served us well. An early draft of itertools.ifilter() had an invert flag. The toolset improved when that was split to a separate function, ifilterfalse().
Tim's rule on algorithm selection: We read Knuth so you don't have to.
Raymond's rule on language proposals: Assertions that construct X is better than an existing construct Y should be backed up by a variety of side-by-side comparisons using real-world code samples.
I'm sure there are plenty more if these in the archives.