On 8/31/05, Charles Cazabon <[EMAIL PROTECTED]> 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
