[Python-Dev] Design Principles

[Raymond Hettinger]

> > 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.

FWIW, after this is over, I'll put together a draft list of these
principles.  The one listed above has served us well.  An early draft of
itertools.ifilter() had an invert flag.  The toolset improved when that
was split to a separate function, ifilterfalse().

Other thoughts:

Tim's rule on algorithm selection:  We read Knuth so you don't have to.

Raymond's rule on language proposals:  Assertions that construct X is
better than an existing construct Y should be backed up by a variety of
side-by-side comparisons using real-world code samples.

I'm sure there are plenty more if these in the archives.


Raymond