[]Brett Cannon <br...@python.org>]
> ...
> Sorry, "needed" was too strong of a word. It's more about justification for
> including in the stdlib and deciding to support it for a decade or more
> versus the answer we give for simple one-liners of "put in your personal
> toolbox if you don't want to type it out every time".
It's slightly tricky to get right. Good enough for me ;-)
Note that I coupled this with leaving it in Python too. `itertools`
has been quite an inactive module this decade, and looks like it would
have enjoyed few commits at all _except_ that it's coded in C.
Commits have been mostly due to C fashion changes, like
Use PyXXX_GET_SIZE macros rather than Py_SIZE for concrete types.
Renamed Py_SETREF to Py_XSETREF
_Py_identifier to _Py_IDENTIFIER
and various bug fixes due to lack of 100% perfect type checking (&
such) at the C level.
The support burden for C code is much higher than for Python code.
> ...
> Sure, but the question I think that this thread and me are proposing are what
> "first()" means to everyone. I think you and I are on the same page, but it's
> a question as to whether others are as well. :)
Except that we're not jumping in cold here. I've been pushing to
adopt _exactly_ what more-itertools has done for years already.
Steven appears to think `first()` shouldn't exist at all unless it's
restricted to container types and spelled in some other way. I'm not
sure anyone else has complained about the intended semantics. People
always argue about end cases, but more-itertools gave a choice in a
simple way: for an exhausted iterator, raise an exception, which can
be suppressed by supplying a default to return instead.
Nobody has actually argued that it should always - or never - raise an
exception in that case. Guido's _implementation_ happened to never
raise an exception, but not even he could be bothered to say a word
about why that may be _desirable_.
And I snipped the rest because it was so relentlessly agreeable ;-)
_______________________________________________
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/4OKVK5WCX4GHE75U5NQTBMHRWRIXJP6M/
Code of Conduct: http://python.org/psf/codeofconduct/
