I can't really imagine Raymond liking this idea, and I have a feeling the idea has been shot down before. However, I can't persuade Google to tell me anything about such an occasion, so here goes anyway. . .

The utilities in the itertools module can easily be composed to provide additional useful functionality (e.g. the itertools recipes given in the documentation [1]).

However, having to recode these every time you need them, or arranging access to a utility module can be a pain for application programming in some corporate environments [2]. The lack of builtin support also leads to many variations on a theme, only some of which actually work properly, or which work, but in subtly different ways [3]. On the other hand, it really isn't worth the effort to code these algorithms in C for the current itertools module.

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).

An alternative approach is based on an idea from Alex Martelli [4]. As Alex points out, itertools is currently more about *creating* iterators than it is about consuming them (the only function desription that doesn't start with 'Make an iterator' is itertools.tee and that starts with 'Return n independent iterators'). 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).

The downside of the latter proposal is that the recipes in the itertools documentation relate both to producing *and* consuming iterators, so a new module would leave the question of where to put the handy iterator producers.

Regards,
Nick.

[1] http://www.python.org/dev/doc/devel/lib/itertools-recipes.html
[2] http://mail.python.org/pipermail/python-list/2005-February/266310.html
[3] http://mail.python.org/pipermail/python-list/2005-February/266311.html
[4] http://groups-beta.google.com/group/comp.lang.python/msg/a76b4c2caf6c435c

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---------------------------------------------------------------
            http://boredomandlaziness.skystorm.net
_______________________________________________
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