[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

Reply via email to