Issue 18752: Make chain.from_iterable an alias for a new chain_iterable. (original) (raw)

It has become apparent from various discussions in recent months that chain.from_iterable is at least as useful as chain. In fact, I now think that 'chain' should have been what chain.from_iterable is, with current chain(a,b,c) done as chain((a,b,d)). But too late for that.

Based on today's pydev post* by Eric Smith, I propose that chain_iterable (or chain_from_iterable, but I think the 'from' is not needed) be added to itertools and listed in the index table and documented as a function in its own right.

This would make the long discussion of how to properly document chain.from_iterable (#18301) moot, as the method could be simply mentioned as a (deprecated) alias of chain_iterable.

• "I think that [itertools.chain.from_iterable] was a mistake, too. As a recent discussion showed, it's not exactly discoverable. The fact that it's not mentioned in the list of functions at the top of the documentation doesn't help. And "chain" is documented as a "module function", and "chain.from_iterable" as a "classmethod" making it all the more confusing.

I think itertools.combinations and itertools.combinations_with_replacement is the better example of related functions that should be followed. Not nested, no special parameters trying to differentiate them: just two different function names."

If this proposal is rejected, then chain.iterable should be added to the index table. That would make it more discoverable, but not less confusing.