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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
