<div dir="ltr">That would get _really_ messy with iterators that define an __add__, sequence concat or number add function<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 4, 2015 at 9:01 PM, Alexander Belopolsky <span dir="ltr"><<a href="mailto:alexander.belopolsky@gmail.com" target="_blank">alexander.belopolsky@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Aug 4, 2015 at 8:43 PM, Joseph Jevnik <<a href="mailto:joejev@gmail.com">joejev@gmail.com</a>> wrote:<br>
> Iterators all all different types though. iter(list) returns a list_iterator<br>
> type, iter(dict.keys()) returns a dict_keys_iterator type and so on. Is your<br>
> suggestion that the standard lib types do this? How do we update all of the<br>
> existing iterators not in the stdlib that do not do this?<br>
<br>
</span>In theory, this can be done inside PyNumber_Add(x, y).  It already<br>
checks for numbers or sequences and failing that can check for the<br>
__next__ method on its first operand and return  itertools.chain(x,<br>
y).<br>
<span class=""><br>
> Finally, how is this better than itertools.chain?<br>
<br>
</span>Shorter.  Especially when you chain more than two iterators.<br>
<br>
Nevertheless, I am -1 on the idea.  It is bad enough that Python<br>
abuses + as sequences concatenation operator.<br>
</blockquote></div><br></div>