On Saturday, July 1, 2017, Steven D'Aprano
On Sat, Jul 01, 2017 at 01:35:29AM -0500, Wes Turner wrote:
On Saturday, July 1, 2017, Steven D'Aprano
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-infinit... - 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/