[Brett Cannon <br...@python.org>] > Thinking out loud here... > > What idiom are we trying to replace with one that's more obviously and whose > semantics are easy to grasp?
For me, most of the time, it's to have an obvious, uniform way to spell "non-destructively pick an object from a container (set, dict, list, deque, heap, tuple, custom tree class, ...)". I don't even have iterators in mind then, except as an implementation detail. For that reason, raising `StopIteration` if the container is empty grates. The _value_ (the state of the container) I passed is inappropriate then, so more-itertool's ValueError makes more sense to me. The toolz.itertoolz version of `first()` differs. That one is just next(iter(argument)). No default. I like the more-itertools flavor better. As to which idiom it intends to replace, _that's_ the annoyance being addressed: there is no "one obvious way to do it" now. Although for each individual container type, there's sometimes an obvious way to do it for objects of that type (e.g., object[0] for a list or heap, or object.root for a rooted tree class). > `first(iterable)` that raises is StopIteration is `next(iter(iterable))`. > `first(iterable)` that > defaults to None and doesn't raise is `next(iter(iterable), None)`. Now only > if the raised > exception changes do you end up with something like Tim's examples where more > than one line is definitely needed. Talking about "needed" is treating this like an axiomatic system where redundancy is in Very Bad Taste. But, to the contrary, in functional languages the _implementers_ think very hard about creating a minimal core, but the user interface supplies everything _useful_ and sometimes doesn't even note whether a thing is part of the minimal core. When I want `first()`, I want `first()`. I don't care how it's implemented, and I couldn't care less that I _could_ write it myself by composing other functions in a brief one-liner. > So I think the question is what problem are we trying to solve here? Is it > the lack of > knowledge of the 2-argument next() form? Or is it that people are regularly > wanting > the first item from an iterable and when it doesn't exist they want to raise > an > exception different from StopIteration (and what is that alternative > exception)? > > If it's the former then I think the case could be made that more education of > the > one-liner might be all that's needed here. Now Guido did the research and > showed > that the stdlib doesn't seem to realize this form really exists, so it might > be quite > the education. ;) `first()` definitely isn't _needed_. Without it, people will continue reinventing their own ad hoc methods of getting it done, and they'll succeed. > But if it's the latter then there's a greater savings in complexity from > providing first() > with those semantics. But once again the question becomes how often does that > come up? Often enough that both relevant packages (more-itertools and toolz.itertoolz) have supplied it for years, although with different endcase behavior. Certainly not often enough to merit being __bulitin__. > I obviously have no answers to provide. :) My gut is suggesting that if it's > the one-liner > replacement it might not be worth it, but if it's to raise a different > exception I could see > more of a use for adding something to the stdlib. As above, `first()` is an atomic concept in my head. It _can_ be synthesized out of more basic concepts, but in the ways I think about getting a problem solved, it's a primitive. As a primitive, passing an empty argument is a ValueError in the absence of also passing an explicit default to return in that case. I can live without it, but that's not really the point ;-) _______________________________________________ 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/UKQUH4DUHXDAYEKWQANSOXOJB7LWZ2LP/ Code of Conduct: http://python.org/psf/codeofconduct/
