Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 8/31/05, Charles Cazabon <[EMAIL PROTECTED]> 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. ... ? Charles -- ----------------------------------------------------------------------- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/software/ ----------------------------------------------------------------------- _______________________________________________ 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
