for_some(), for_all()?

[Raymond Hettinger]

[Michael Hoffman]
> Nice! I've always found the itertools examples exceptionally useful. Is
> there a reason why they aren't in the standard library? I find myself
> copying and pasting the snippets all the time.

[Michele Simionato]
> I always wondered why "any" and "all" are given as recipes but are not
> part of the itertools module. What is the rationale?
> I think they are so common that they deserve to be in the module.
> At least, we would have standard names.


Random thoughts on itertools recipes and module design:

* The recipes are formatted to make it easy to paste the whole thing into a
module (it's already there for the taking).

* Adding more tools to the basic set makes the module itself harder to learn.  I
theorize that the difficulty of creating a new composite tool grows
exponentially with the number of available fundamental building blocks.

* The recipes have as much value as a teaching tool as they do for practical
applications.  Study the page of recipes and you've mastered itertools for life.

* Once in the standard library, the API is set in concrete.  But as part of the
docs, I'm free to backport, improve variable names, improve function names,
substitute alternate approaches, and drop recipes that don't prove themselves in
battle.

* Publishing the recipes is a step toward standardizing the naming and
collecting best practices.  IOW, we already get some of the benefits without
having to include the functions in the standard library.

* If included in the library, some of the functions would grow more complex.
For example, the pred=bool default needs to be followed by "if pred is bool:
pred=None" to take advantage of the ifilter's faster internal call to bool.

* Until now, there has been no popular demand. If the demand grows, I'll oblige
and include some of them in Py2.5.  I prefer to be careful.  Being conservative
about what goes in the module has contributed substantially to its success.

* Some derived tools like padnone() arise infrequently and are rarely the right
solution for a problem (not many functions respond well to a data stream where
one field suddenly starts yielding None).  This function takes more than a
modicum of skill to use correctly.  It is there to show how it is done and to
provide an iterator solution for folks relying on map()'s None fill-in feature.
IOW, it is not deserving of being in the standard library.

* Leaving the derived tools as recipes creates a sense that that more
combinations are open for invention.  Putting them in the module suggests that
the problem is closed.  This of course isn't strictly true, but it does affect
the mood.



Raymond Hettinger