[issue18652] Add itertools.coalesce

Tim Peters added the comment: > skipping the underscore ("firsttrue" or "nexttrue") > would arguably be more consistent with other itertools names. Like izip_longest and combinations_with_replacement? ;-) I care about readability here more than consistency with the bulk of itertools names. "f

[issue18652] Add itertools.coalesce

Nick Coghlan added the comment: A wild timbot appears! :) Tim Peters added the comment: > As to the name, I like "first_true". Does what it says. Plain "first" is misleading, and "coalesce" is both inscrutable and nearly impossible to spell ;-) A fair point, although skipping the underscore (

[issue18652] Add itertools.coalesce

Hynek Schlawack added the comment: > But why you want to have a separate function instead of just use two builtins? This question has been answered twice now, once from Nick – please refer above. It's a clunky and error-prone solution to a common problem. Maybe you can't emphasize because it's

[issue18652] Add itertools.coalesce

Tim Peters added the comment: FWIW, I like this. It would be a nice addition to the itertools module. +1 The `key` argument should be renamed to `pred`, as others have said. As to the name, I like "first_true". Does what it says. Plain "first" is misleading, and "coalesce" is both inscrutab

[issue18652] Add itertools.coalesce

Serhiy Storchaka added the comment: > Well, for many – including me – it would mean to have this one-line function > in every other project or a PyPI dependency. But why you want to have a separate function instead of just use two builtins? -- ___ P

[issue18652] Add itertools.coalesce

R. David Murray added the comment: I'm not going to object to the name, since I see that it is used elsewhere in programming for the proposed meaning. But allow me to rant about the corruption of the English language here. To me, "coalesce" should involve a computation based on all of the el

[issue18652] Add itertools.coalesce

Hynek Schlawack added the comment: > def coalesce(iterable, default=None, pred=None): >return next(filter(pred, iterable), default) > > Are you sure you want add this one-line function to the itertools module > rather then to recipes? Well, for many – including me – it would mean to ha

[issue18652] Add itertools.coalesce

Serhiy Storchaka added the comment: def coalesce(iterable, default=None, pred=None): return next(filter(pred, iterable), default) Are you sure you want add this one-line function to the itertools module rather then to recipes? -- ___ Python

[issue18652] Add itertools.coalesce

Nick Coghlan added the comment: Mark's rationale makes sense to me. I believe that would make the latest version of the proposed API (in the itertools module): def coalesce(iterable, default=None, pred=None): ... -- ___ Python tracker

[issue18652] Add itertools.coalesce

Mark Dickinson added the comment: [Nick] > Regarding the key parameter name, I believe this is closer to > itertools.groupby ... Isn't this mostly about the return type? `pred` is an indication that a boolean is being returned (or that the return value will be interpreted in a boolean context

[issue18652] Add itertools.coalesce

Martin v. Löwis added the comment: Simplicity is in the eye of the beholder, yet... you need to remember the break when *writing* the code, so the loop might be more difficult to write (but then, I need to remember/lookup the function name and parameters for coalesce)... when reading the code,

[issue18652] Add itertools.coalesce

Nick Coghlan added the comment: (Updated the issue title to reflect the currently proposed name and location for the functionality) While I'm a fan of explicit iteration as well ("inside every reduce is a loop trying to get out"), I think the fact Martin's explicit loop is buggy (it will neve