[Python-ideas] + operator on generators
wes.turner at gmail.com
Sat Jul 1 10:38:02 EDT 2017
On Saturday, July 1, 2017, Steven D'Aprano <steve at pearwood.info> wrote:
> On Sat, Jul 01, 2017 at 01:35:29AM -0500, Wes Turner wrote:
> > On Saturday, July 1, 2017, Steven D'Aprano <steve at pearwood.info
> > > 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
> > > 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?
> > - So there's then a new conditional import (e.g. in a compat package)?
> > 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)
- AFAIU, + doesn't work because e.g. numpy already defines + and & for
> > > > ¹ 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__(),
> > > > 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
> > > If you're sending values
> > > into an arbitrary generator, who knows what you're getting? chain()
> > > 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?
> Python-ideas mailing list
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas