[Guido] > We're not changing next(). It's too fundamental to change even subtly.
Note that `next()` already accepts two arguments (the second is an optional default in case its iterable argument is exhausted). Like: >>> next(iter([]), 42) 42 > We might add itertools.first(), but not builtins.first(). This kind of > functionality > is not fundamental but it's easy to get slightly wrong (witness many hasty > attempts in these threads). > > itertools.first() should be implemented in C, but its semantics should be > given by this (well, let me see if I can get it right): > > def first(it, /, default=None): > it = iter(it) > try: > return next(it) > except StopIteration: > return default Or, more succinctly, the body can be replaced by: return next(iter(it), default) I expect - but don't know - that people who think `first()` is a trivial use of `next()` have that in mind. I'd nevertheless like to see it in `itertools`. But then functional languages have a long tradition of supplying all sort of things trivially spelled in terms of other things, and I believe that tradition is appropriate _in that context_ (when your view of the world builds on layering functions, you don't want to stop to write a common boilerplate function no matter how trivial it is, and neither do functional language readers want to stop to figure out how _you_ named a common boilerplate function). In other words, in that context, the bar for "building it in" consists far more of "will it be used?" than "is it difficult or tricky or long-winded?". _______________________________________________ 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/5Z6Y6DFQ474PVDGPYCKCZXHWX2N5C7UL/ Code of Conduct: http://python.org/psf/codeofconduct/
