On Jun 4, 6:44 pm, "Gabriel Genellina" <gagsl-...@yahoo.com.ar> wrote: > En Thu, 04 Jun 2009 10:37:45 -0300, pataphor <patap...@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 -- http://mail.python.org/mailman/listinfo/python-list
