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.

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.

Op 25 jun. 2017 2:51 p.m. schreef "Serhiy Storchaka" <storchaka@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.

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.