Generators' and iterators' __add__ method
Wouldn't it be nice to add generators and iterators like we can do with lists? def f(): yield 1 yield 2 yield 3 def g(): yield 4 yield 5 # today for item in itertools.chain(f(), g()): print(item) # proposal for item in f() + g(): print(item) What do you guys think? Yuval Greenfield
It's been proposed many times, but always stumbled on the fact that the iterator protocol doesn't have a standard implementation -- each object implementing __next__ would have to be modified separately to also support __add__. On Wed, Feb 15, 2012 at 8:20 AM, Yuval Greenfield <ubershmekel@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)
On 2/15/2012 11:20 AM, Yuval Greenfield wrote:
Wouldn't it be nice to add generators and iterators like we can do with lists?
That is simply not possible. list1+list2 is a list; tuple1+tuple2 is a tuple; list1+tuple2 is an error! What type would iterable1 + iterable 2 be? Answer: a chain object!
The itertools module is the proper place for generic operations on iterables (and not just iterators!).
Chain 'adds' mixed types and is not limited to binary scope. If we were starting fresh today, we *might* consider making the functions that went into itertools into methods of an iterable ABC. But making every function a method is not Python's style. Indeed, exposing generic methods like __len__ as functions is more common. -- Terry Jan Reedy
Well, it looks like a classical problem of disambiguisation. We have more than one consistent behaviour for addition. (I know I am dense). And these behaviours clash if not properly disambiguized. In a world were unicorns exists, we would select the behaviour of __add__ with a switch (let's say __add__ would be a dispatch table that would take the «algebrae» as a parameter). Still in this world were unicorns exists and Perl6 would be in production (and acclaimed) this switch could be sensibily set according to the context. And everybody would be perfectly aware and taking no dangers. In the actual word, it is pretty much a chimera or a dying foetus (musical joke) in the case of python since it would violates half the tao of python : ... Explicit is better than implicit. ... Complex is better than complicated. ... Special cases aren't special enough to break the rules. ... There should be one-- and preferably only one --obvious way to do it. As a result my suggestion for the FAQ should be to state that anyone wanting to submit an idea to python community should «import this» first and see it as deadly serious. I made the mistake twice :) PS I still see cases were having an __algebrae__ private member could be very helpful, because dynamic typing has its limit. hf, gl -- Jul
It's been proposed many times, but always stumbled on the fact that the iterator protocol doesn't have a standard implementation -- each object implementing __next__ would have to be modified separately to also support __add__. On Wed, Feb 15, 2012 at 8:20 AM, Yuval Greenfield <ubershmekel@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)
On 2/15/2012 11:20 AM, Yuval Greenfield wrote:
Wouldn't it be nice to add generators and iterators like we can do with lists?
That is simply not possible. list1+list2 is a list; tuple1+tuple2 is a tuple; list1+tuple2 is an error! What type would iterable1 + iterable 2 be? Answer: a chain object!
The itertools module is the proper place for generic operations on iterables (and not just iterators!).
Chain 'adds' mixed types and is not limited to binary scope. If we were starting fresh today, we *might* consider making the functions that went into itertools into methods of an iterable ABC. But making every function a method is not Python's style. Indeed, exposing generic methods like __len__ as functions is more common. -- Terry Jan Reedy
Well, it looks like a classical problem of disambiguisation. We have more than one consistent behaviour for addition. (I know I am dense). And these behaviours clash if not properly disambiguized. In a world were unicorns exists, we would select the behaviour of __add__ with a switch (let's say __add__ would be a dispatch table that would take the «algebrae» as a parameter). Still in this world were unicorns exists and Perl6 would be in production (and acclaimed) this switch could be sensibily set according to the context. And everybody would be perfectly aware and taking no dangers. In the actual word, it is pretty much a chimera or a dying foetus (musical joke) in the case of python since it would violates half the tao of python : ... Explicit is better than implicit. ... Complex is better than complicated. ... Special cases aren't special enough to break the rules. ... There should be one-- and preferably only one --obvious way to do it. As a result my suggestion for the FAQ should be to state that anyone wanting to submit an idea to python community should «import this» first and see it as deadly serious. I made the mistake twice :) PS I still see cases were having an __algebrae__ private member could be very helpful, because dynamic typing has its limit. hf, gl -- Jul
participants (6)
-
anatoly techtonik -
Greg Ewing -
Guido van Rossum -
julien tayon -
Terry Reedy -
Yuval Greenfield