[Python-ideas] + operator on generators

[Wes Turner]

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
> <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 at python.org <javascript:;>
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170701/9c1eb922/attachment.html>