Tim Peters wrote:
> It's fair enough, although rather than "wrong" I'd say more that it's
> inappropriately applying design principles that work well in most of
> Python's libraries to an area where they don't. The very fact that
> half the itertools docs are devoted to "recipes" kinda suggests it
> knows it's leaving its intended audience hanging ;-)
Yeah I'm personally not a huge fan of how large the recipes section of
itertools is, compared to the actual module contents. My personal opinion
is that the recipes section should be primarily for niche or complex
algorithms that wouldn't be general purpose enough to be used for the
module, but still have legitimate use cases. If it's general purpose enough
and has a legitimate use case, it should be added as a function, not as a
recipe.
Instead, it seems to have gradually turned into: "Put everything in the
recipes section that might be useful and can be implemented using existing
tools, even if adding a dedicated function would be more readable. Only add
a new function if it doesn't already exist in some other form, no matter
how obscure." (oversimplified, but that's been my interpretation). The last
time a new function was added to itertools was back in 3.2 (2011), for
itertools.accumulate().
I think itertools.first() is a good example of something that would be
useful and general-purpose enough to be included as a function in
itertools. `first_item = first(iterable)` is much easier to read than
`first_item = next(iter(iterable))`, not to mention first(iterable) raising
a ValueError instead of StopIteration on an empty iterable, which seems
much more clear to me.
I also find the default version (where an exception isn't raised) to be a
lot easier to read with first, especially if *default* is able to be
passed as a keyword argument. Compare `first_item = first(iterable,
default=None)` to `first_item = `next(iter(iterable), None)` (next doesn't
take any kwargs).
If even those who have been involved with Python's development since its
infancy aren't overly familiar with 2-arg next(), how could we reasonably
expect the average user to be? I'll admit that I had not even heard about
the 2-arg next() until reading the posts in this thread. My method of
extracting the first value from an iterable (when I wanted it to default to
None instead of raising StopIteration) was:
```py
try:
first_item = next(iter(iterable))
except StopIteration:
first_item = None
```
On Tue, Dec 10, 2019 at 8:15 PM Tim Peters <tim.pet...@gmail.com> wrote:
> [Andrew Barnert <abarn...@yahoo.com>]
> > ...
> > I think you’re arguing that the philosophy of itertools is just wrong,
> at least for
> > the kind of code you usually write with it and the kind of people who
> usually
> > write that code. Is that fair, or am I misrepresenting you here?
>
> It's fair enough, although rather than "wrong" I'd say more that it's
> inappropriately applying design principles that work well in most of
> Python's libraries to an area where they don't. The very fact that
> half the itertools docs are devoted to "recipes" kinda suggests it
> knows it's leaving its intended audience hanging ;-)
>
> It's hardly coincidence that the more-itertools and itertoolz packages
> are richer, in very similar ways, than Python's version. The primary
> itertoolz author does a nice job of explaining that project's heritage
> starting here:
>
> https://toolz.readthedocs.io/en/latest/heritage.html
>
>
> > Meanwhile, I think Guido and some others accept the itertools philosophy
>
> Don't know about Guido, but certainly applies to Raymond. Guido is
> more a practicality-beats-purity guy. but has no natural attraction to
> functional languages (Raymond partly does, with his APL background).
> Guido just sees a function here that would be nice to have.
>
> I do like functional languages, and always have, so it seems to fall
> on me here to advocate for what those weirdos value. In part, no, the
> itertools namespace is not a precious resource that must be vigilantly
> minimized ;-)
>
>
> > but argue that first needs to be there because many of the kinds of
> people who
> > need it actually can’t just write it themselves (they don’t know about
> 2-arg next,
> > or they don’t understand the subtleties of leaking StopIteration, or
> whatever).
> > That’s a pretty different argument. (Not that there can’t be something
> to both
> > arguments, of course.)
>
> And I expect Raymond would say `first()` isn't needed at all - if it
> has to be addressed, make it recipe #30.
>
> There's something to that argument too.
> _______________________________________________
> 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/JPOU2L3RWCRCRZ37EPSNJLI4DF4LUNBX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
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/YWGXO7634NLOTFWVI4UD2CMZ6WKIXX6U/
Code of Conduct: http://python.org/psf/codeofconduct/
