Guido van Rossum email@example.com wrote:
On 8/31/05, Charles Cazabon firstname.lastname@example.org wrote:
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:
Ah, excellent response. Are your design principles written down anywhere? I didn't see anything on your essays page about them, but I'd like to learn at the feet of the BDFL.
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.
Hmmm. I really dislike the additional names, but ...
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;
I can see this.
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;
This I don't think is so bad. It's analogous to providing the "reverse" parameter to sorted et al, and I don't think that's particularly hard to remember. It would also be rarely used; I use find/index tens of times more often than I use rfind/rindex, and I presume it would be the same for a hypothetical .part/.rpart.
also, a Boolean positional argument is a really poor clue about its meaning, and it's easy to misremember the sense reversed.
I totally agree. I therefore borrowed the time machine and modified my proposal to suggest it should be a keyword argument, not a positional one :).
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.
Hmmm. In all of these cases, the type of the return value is constant. Only the value would change based on the value of the arguments. ... ?