[Python-ideas] + operator on generators

[Terry Reedy]

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