>itertools.window() with n=2 got rejected. Almost all proposed uses had better > >solutions (such as an accumulator variable or fibonacci sequence style logic: > >a, b = b, a+b). Writing it in C afforded only small speed advantage over a > >solution using izip() and tee().
[Christos TZOTZIOY Georgiou] > Speed or C implementation was not my objection. . . . > Just make it > readily available. I volunteer for a patch if we agree on it[1]. No thanks. A patch was developed, discussed, and rejected long ago. The main reason was that existing approaches were often better (at least in the context of the use cases that we reviewed). Performance was mentioned because that is sometimes used to justify a new tool. In this case, that justification was not strong. > None of the > itertools.(queue|roundrobin|accumulate|multi_gen|remove_value|eq|consume|ilines) > that you reference exists as a recipe in the docs. FWIW, the recipe for roundrobin is at: http://docs.python.org/lib/deque-recipes.html . The only other one worth further discussion is iterequals(). I held-off publishing that one because the opportunites for error were too great (see the previous post for details). > Did I make you believe I cared about the fate of any function judged unworthy > even for the documentation? No. My note was mainly for the benefit of those who had an interest in what type of ideas had been discussed and the reasoning behind their inclusion/exclusion. It needed to be documented somewhere and the newsgroup discussion on a couple of proposals provided an opportunity to put those notes on record. > I'm just whining that putting recipes in the docs as an 'extended > toolset' instead of in a module is a joking compromise... Not really. The recipes have several uses and none of them are compromises. Firstly, they serve as a proving ground which helps inform further development. As a recipe, they can be readily altered, improved, or removed without breaking anything. However, once I include them as part of the module, the API gets frozen, as do any accidents of implementation. Once released, the process of making repairs or alterations becomes slow and painful. Over time, some of the recipes will disappear. some will evolve, and some will work their way into a module (witness any() and all() as recent examples). By way of comparision, consider the evolution of set()/frozenset() which went through stages as recipes, as a PEP, then as Python module, and finally as C coded built-ins. That multi-stage process was deliberate and resulted in the final version being excellent. Similarly, many new decorators are going to start their lives as wiki entries or recipes. Ultimately, some will make it into the standard library. It would be a mistake to make that transition too quickly. The other purpose of the itertool recipes is to serve as a teaching tool showing how to combine the tools and how to integrate them with other Python code. IMO, most of the recipes are more useful in this capacity than as immediate solutions to particular problems. Raymond Hettinger -- http://mail.python.org/mailman/listinfo/python-list
