On 8/31/05, Charles Cazabon <python at discworld.dyndns.org> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4