On 6/27/2017 10:47 PM, Nick Coghlan wrote:
While I haven't been following this thread closely, I'd like to note that arguing for a "chain()" builtin has the virtue that would just be arguing for the promotion of the existing itertools.chain function into the builtin namespace.
Such an approach has a lot to recommend it:
1. It has precedent, in that Python 3's map(), filter(), and zip(), are essentially Python 2's itertools.imap(), ifilter(), and izip() 2. There's no need for a naming or semantics debate, as we'd just be promoting an established standard library API into the builtin namespace
A counter-argument is that there are other itertools that deserve promotion, by usage, even more. But we need to see comparisons from more that one limited corpus. On the other hand, there might be a theory argument that chain is somehow more basic, akin to map, etc, in a way that others are not.
3. Preserving compatibility with older versions is straightforward: just do an unconditional "from itertools import chain" 4. As an added bonus, we'd also get "chain.from_iterable" as a builtin API
So it would be good to have a short PEP that argued that since chaining arbitrary iterables is at least as important as mapping, filtering, and zipping them, itertools.chain should be added to the builtin namespace in 3.7+ (but no, I'm not volunteering to write that myself).
As a *separate* discussion, folks could then also argue for the additional of a `__lshift__` operator implementation specifically to iterator chains that let you write:
full_chain = chain(it1) << it2 << it3 # Incrementally create new chains full_chain <<= it4 # Extend an existing chain
I'd be surprised if such a proposal got accepted for 3.7, but it would make a good follow-up discussion for 3.8 (assuming chain() made it into the 3.7 builtins).
-- Terry Jan Reedy