I agree here, and don't recommend it to newbies -- a bit less for your reasons than that it encourages really horrible software development practices -- cutting and pasting utility functions from one notebook to a new one, and essentially impossible to unit test..

But I do use, and recommend the iPython repl, and completion is really handy there, too :-)

However, I"m not sure "you could find it with completion" is really the reason to put something in a module rather than as a recipe.

Implementation aside, I think the criteria should be something like:

If it's generally useful and not totally trivial (i.e. one line of code), then put it in.

If it's a generally useful *pattern*, but individual use cases are likely to need to specialize it a bit, then it should be a recipe.

As for "consume" -- I think it very much meets the requirement of non-trivial and generally useful.

The other issue here, in the context of the OP's proposal, is that it's less than obvious that that's what a user would want when they want to operate on all the items in a iterable without creating a new iterable. To Guido's point, the way to do this now is:

for i in an_iterable: act_on(i)

Is simple, obvious and compact, though not "functional" or "using the comprehension syntax". Indeed, I proposed a couple years ago that some sort of "make nothing comprehension" would be good, and the idea was rejected, and I was pointed to that simple for loop as "the one obvious way to do it". At that time no one pointed me to consume, or anything like it, but I still think that:

consume(act_on(i) for i in an_iterable)

wouldn't be what I recommend, even if consume was built in to itertools.

while yes, performant and using comprehension syntax is nice, it's still uglier, less obvious, and less discoverable than the simple for loop.

Back to consume() as a built in to itertools -- looking at the recipe, it's good to have that recipe, as it takes advantage of a hidden performance trick in deque -- hardly anyone is going to come up with that on their own! But frankly, given that itertools is written in C anyway, it seems a high performance written-in-C implementation would be a fine idea. It just seem pretty basic to be -- something that should be a building block, rather than a wrapper around what looks like a higher level class.

Not that I'm offering to write the code ... But if "someone would need to write the code" is the only stumbling block, maybe I would (or I'd bet someone would step up).

-CHB