On Aug 1, 2019, at 00:06, Eli Berkowitz
These are all fair and good points :)
I really like the idea of writing a function that exhausts an iterator and using that. It seems like this should be a part of the itertools package at least, maybe called `run`, `do`, or `exhaust`.
There’s already the consume(iterator, n=None) function in the recipes section of the docs: "Advance the iterator n-steps ahead. If n is None, consume entirely." It’s only 4 lines of code, and you can copy and paste it from the code. Or, if you don’t need the optional n, the function is just a one-liner. There’s been discussion in the past about moving some of the recipes into the module itself. Besides consume, functions like grouper and unique_everseen have pretty common and broad uses, and they’re less trivial, and you can’t quite just copy-paste them (unless you want to from itertools import * they need minor edits). I think the original reason not to do so was that the module was pure C code, and the recipes don’t need to be in C, and are as useful as sample code as they are for direct use, so they should remain in Python. Given that in 3.x every stdlib module is supposed to be in Python with an optional C accelerator, that might not be as compelling anymore. But you’d still need to overcome the conservative presumption of the status quo with a good argument. Meanwhile, the third-party library more_itertools includes all of the recipes (and it’s kept up-to-date, so the occasional new recipes are available to anyone who installs it, even with older versions of Python). So, just add that to your requirements file, and you can import consume from more_itertools instead of itertools.