[Nick Coghlan] > If itertools was a hybrid module, the handy 3-4 liners could go in the Python > section, with the heavy lifting done by the underlying C module. The Python > equivalents to the current C code could also be placed in the hybrid module > (as > happens with some of the other hybrid modules in the library).
Both of those ideas likely reflect the future direction of itertools. FWIW, the historical reasons for keeping the derived tools in the docs were: * Not casting them in stone too early so they could be updated and refined at will. * They had more value as a teaching tool (showing how basic tools could be combined) than as stand-alone tools. * Adding more tools makes the whole toolset harder to use. * When an itertool solution is not immediately obvious, then a generator solution is likely to be easier to write and more understandable. Your two alternate partitioning recipes provide an excellent case in point. * Several of the derived tools do not arise often in practice. For example, I've never used tabulate(), nth(), pairwise(), or repeatfunc(). > Alex's idea would involve adding a module with a new name that is > focused on *consuming* iterators (IOW, extending the available standard > accumulators beyond the existing min(), max() and sum() without further > populating the builtins). That would be nice. From the existing itertool recipes, good candidates would include take(), all(), any(), no(), and quantify(). Raymond _______________________________________________ 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
