Making the case for repeat

[Carl Banks]

On Jun 4, 6:44 pm, "Gabriel Genellina" <gagsl-... at yahoo.com.ar> wrote:
> En Thu, 04 Jun 2009 10:37:45 -0300, pataphor <patap... at gmail.com> escribió:
>
> > So here is my proposed suggestion for a once and for all reconciliation
> > of various functions in itertools that can not stand on their own and
> > keep a straight face. Because of backwards compatibility issues we
> > cannot remove them but we can boldly jump forward and include the right
> > repeat in the builtin namespace, which I think would be the best thing.
> > Alternatively -- the second best solution -- would be to give this
> > function its own namespace where it can supersede the old incongruencies
> > in itertools. Combiniter or combinator?
>
> Ok, you're proposing a "bidimensional" repeat. I prefer to keep things
> simple, and I'd implement it in two steps.


That's brings up a good software engineering question:  What is
better, to have one function with lots of functionality, or many
functions with a single functionality?

Before anyone follows up with the obvious answer, hear me out.

Small functions that do one thing well are almost always a good thing,
but there is a significant benefit to cramming a lot of functionality
into one function: it forces you to hit all corners of a problem.
That is, at least for problems where it makes sense to hit all the
corners of the input space.

The subprocess module is the best example of this.  Pretty much any
combination of arguments to subprocess.Popen makes sense.  If I want
to spawn a process with pipes to standard input and standard error,
but not standard output, that allows me to specify a custom
environment, that uses no buffering, and that goes through the
shell... I can!  Not so with the mish-mash of other calls.

By having a single function doing all that it enabled all those
combinations, something that wouldn't have happened with lots of small
functions.  (I suddenly wonder what other languages have such easy
versatilty in spawning subprocesses.)

So... there is something to be said for pataphor's unified repeat
function.

Having said that, the nature of iterators is that they are easily
recombinable.  This is very much unlike the different options with
subprocesses.  It's not like you can make an extra call just to tack
on some behavior to a simple subprocess-spawning function, but with
iterators you can.  In fact, iterators are (almost) orthogonally
recombinable; the whole input space of a problem can be spanned simply
by combining simple iterators.

So, I will have to ultimately agree with Gabriel: itertools are best
kept simple and complex interator behavior like you suggest is best
done by combining simple iterators.


Carl Banks