On Thu, Aug 1, 2019 at 10:49 AM Eli Berkowitz <eliberkow...@gmail.com> wrote:
> In terms of an argument for why it should be included, for most Python > users the itertools recipes remain unseen. I consider myself relatively > fluent in Python (not compared to y'all of course) and hadn't seen them > until I started this thread. If I had to hazard a guess, they're probably > unused by 95%+ of the Python userbase. > Having a function like consume as a builtin or part of a library widely > increases visibility, and as it's a clean and efficient way of running an > expression on a collection of data I think it's worth it especially as it > has very little overhead. > > Also, given that `consume_iterator` is already in CPython in the > collections module as a special case for `collections.deque(..., maxlen=0)` > (and maybe some other things), I'm guessing it would not be hard at all to > add consume to the itertools module, though I'll be honest I have no idea > how Python's underlying C code fits together at the module level. > > https://github.com/python/cpython/blob/master/Modules/_collectionsmodule.c#L368 > This is an interesting phenomenon. I'm not saying it's good or bad, I'm just observing it (because it surprised me). Here is someone declaring that the docs are less accessible than the code. I personally am disappointed, given the amount of effort that we put in those docs. But maybe this is true. If we can't get people to peruse the docs, should we bother? OTOH suppose you have this problem, of wanting to call a function over an iterator without producing a list of dummy results. Presumably you're aware of the obvious solution (`for x int xs: f(x)`). What drives you to look for a purely functional approach? How do you know to search for "consume iterator"? (I Googled this, and the top two hits are a StackOverflow question about the specific meaning of "consuming", and the itertools docs -- apparently in those docs, everything "consumes" iterators.) How do you know this isn't premature optimization? (I bet we've collectively spent more energy on this thread than Facebook could save in a year by using whatever solution we could create. :-) I learned something in this thread -- I had no idea that the deque datatype even has an option to limit its size (and silently drop older values as new ones are added), let alone that the case of setting the size to zero is optimized in the C code. But more importantly, I don't think I've ever needed either of those features, so maybe I was better off not knowing about them? Have we collectively been nerd-sniped by an interesting but unimportant problem? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SUBU2DZC2764X5HWRJMCYMWNEQ433IPL/ Code of Conduct: http://python.org/psf/codeofconduct/
