Personally, I find syntactic sugar for concating interators would come
in handy.
The purpose of iterators and generators is performance and efficiency.
So, lowering the bar of using them is a good idea IMO. Also hoping back
and forth a generator/iterator-based solution and a, say,
list-based/materialized solution would become a lot easier.
On 25.06.2017 16:04, Stephan Houben wrote:
I would like to add that for example numpy ndarrays are iterables, but
they have an __add__ with completely different semantics, namely
element-wise ( numerical) addition.
So this proposal would conflict with existing libraries with iterable
objects.
I don't see a conflict.
Op 25 jun. 2017 2:51 p.m. schreef "Serhiy Storchaka"
<storch...@gmail.com <mailto:storch...@gmail.com>>:
It would be weird if the addition is only supported for instances
of the generator class, but not for other iterators. Why (n for n
in range(2)) + (n for n in range(2, 4)) works, but iter(range(2))
+ iter(range(2, 4)) and iter([0, 1]) + iter((2, 3)) don't?
itertools.chain() supports arbitrary iterators. Therefore you will
need to implement the __add__ method for *all* iterators in the world.
I don't think it's necessary to start with *all* iterators in the world.
So, adding iterators and/or generators, should be possible without any
problems. It's a start and could already help a lot if I have my
use-cases correctly.
However itertools.chain() accepts not just *iterators*. It works
with *iterables*. Therefore you will need to implement the __add__
method also for all iterables in the world. But __add__ already is
implemented for list and tuple, and many other sequences, and your
definition conflicts with this.
As above, I don't see a conflict.
Regards,
Sven
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
