On Saturday, July 1, 2017, Steven D'Aprano <st...@pearwood.info> wrote:
> On Sat, Jul 01, 2017 at 01:35:29AM -0500, Wes Turner wrote: > > On Saturday, July 1, 2017, Steven D'Aprano <st...@pearwood.info > <javascript:;>> wrote: > > > > > On Fri, Jun 30, 2017 at 01:09:51AM +0200, Jan Kaliszewski wrote: > > > > > > [...] > > > > > > But the more I think about it the more I agree with Nick. Let's start > > > by moving itertools.chain into built-ins, with zip and map, and only > > > consider giving it an operator after we've had a few years of > experience > > > with chain as a built-in. We might even find that an operator doesn't > > > add any real value. > > > > > > - Would that include chain.from_iterable? > > Yes. > > > - So there's then a new conditional import (e.g. in a compat package)? > What > > does this add? > > try: chain > except NameError: from itertools import chain > > Two lines, if and only if you both need chain and want to support > versions of Python older than 3.7. > > There's no need to import it if you aren't going to use it. Or, can I just continue to import the same function from the same place: from itertools import chain Nice, simple, easy. There's even (for all you functional lovers): from itertools import * And, again, this works today: from fn import Stream itr = Stream() << my_generator() << (8,9,0) - https://github.com/kachayev/fn.py/blob/master/README.rst#streams-and-infinite-sequences-declaration - https://github.com/kachayev/fn.py/blob/master/fn/stream.py - AFAIU, + doesn't work because e.g. numpy already defines + and & for Iterable arrays. > > > > > > ยน Preferably using the existing `yield from` mechanism -- because, in > > > > case of generators, it would provide a way to combine ("concatenate") > > > > *generators*, preserving semantics of all that their __next__(), > send(), > > > > throw() nice stuff... > > > > > > I don't think that would be generally useful. > > > > Flatten one level? > > Flattening typically applies to lists and sequences. > > I'm not saying that chain shouldn't support generators. That would be > silly: a generator is an iterable and chaining supports iterables. I'm > saying that it wouldn't be helpful to require chain objects to support > send(), throw() etc. So the argspec is/shouldbe Iterables with __iter__ (but not necessarily __len__)? > > > > If you're sending values > > > into an arbitrary generator, who knows what you're getting? chain() > will > > > operate on arbitrary iterables, you can't expect to send values into > > > chain([1, 2, 3], my_generator(), "xyz") and have anything sensible > > > occur. > > > > > > - is my_generator() mutable (e.g. before or during iteration)? > > It doesn't matter. Sending into a chain of arbitrary iterators isn't a > useful thing to do. So, with a generator function, I get a traceback at the current yield statement. With chain() I get whatever line the chain call is on. > > > > - https://docs.python.org/2/reference/expressions.html#generator.send > > Why are you linking to the 2 version of the docs? We're discusing a > hypotheticial new feature which must go into 3, not 2. In your opinion, has the send() functionality changed at all? > > > -- > Steve > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org <javascript:;> > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
