On 8/31/05, Charles Cazabon email@example.com wrote:
I would think that perhaps an optional second argument to the method that controls whether it searches from the start (default) or end of the string might be nicer than having two separate methods, even though that would lose parallelism with the current .find/.index.
While I'm at it, why not propose that for py3k that .rfind/.rindex/.rjust/.rsplit disappear, and .find/.index/.just/.split grow an 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.