On 28 June 2017 at 14:30, Terry Reedy <tjre...@udel.edu> wrote: > On 6/27/2017 10:47 PM, Nick Coghlan wrote: >> 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.
The main rationale I see is the one that kicked off the most recent discussion, which is that in Python 2, you could readily chain the output of map(), filter(), zip(), range(), dict.keys(), dict.values(), dict.items(), etc together with "+", simply because they all returned concrete lists. In Python 3, you can't do that as easily anymore, since they all return either iterators or computed containers that don't support "+". While there are good reasons not to implement "+" on those iterators and custom containers, we *can* fairly easily restore builtin concatentation support for their outputs, and we can do it in a way that's friendly to all implementations that already provide the itertools.chain API. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
