Mailman 3 Generators' and iterators' __add__ method - Python-ideas - python.org

newer
Fwd: Re: doctest

Generators' and iterators' add method

older
automation of __repr__/__str__ for...

Yuval Greenfield

15 Feb 2012 15 Feb '12

4:20 p.m.

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

Attachments:

attachment.htm (text/html — 693 bytes)

Reply

Sign in to reply online Use email software

Show replies by date

Guido van Rossum

15 Feb 15 Feb

4:41 p.m.

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 wrote:

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

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- --Guido van Rossum (python.org/~guido)

Reply

Sign in to reply online Use email software

Yuval Greenfield

4:50 p.m.

On Wed, Feb 15, 2012 at 6:41 PM, Guido van Rossum wrote:

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__.

If it isn't a bad idea then we can at least do generators and whatever we find in the standard lib. I think I extrapolate from your response that it isn't a bad idea. I'll work on a patch. Cheers, Yuval

Reply

Sign in to reply online Use email software

Guido van Rossum

4:54 p.m.

It IS a bad idea. --Guido van Rossum (sent from Android phone) On Feb 15, 2012 8:50 AM, "Yuval Greenfield" wrote:

On Wed, Feb 15, 2012 at 6:41 PM, Guido van Rossum wrote:

...
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__.

If it isn't a bad idea then we can at least do generators and whatever we find in the standard lib.

I think I extrapolate from your response that it isn't a bad idea. I'll work on a patch.

Cheers,

Yuval

Reply

Sign in to reply online Use email software

Greg Ewing

16 Feb 16 Feb

1:48 a.m.

On 16/02/12 05:50, Yuval Greenfield wrote:

If it isn't a bad idea then we can at least do generators and whatever we find in the standard lib.

It's only a good idea if it applies universally, otherwise code that relies on it would be fragile. -- Greg

Reply

Sign in to reply online Use email software

Terry Reedy

15 Feb 15 Feb

10:39 p.m.

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!

def f(): yield 1 yield 2 yield 3

def g(): yield 4 yield 5

# today for item in itertools.chain(f(), g()): print(item)

The itertools module is the proper place for generic operations on iterables (and not just iterators!).

...
...
import itertools as it list(it.chain([1,2,3], (4,5.6), range(7,10))) [1, 2, 3, 4, 5.6, 7, 8, 9]

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

Reply

Sign in to reply online Use email software

Greg Ewing

16 Feb 16 Feb

1:46 a.m.

On 16/02/12 05:20, Yuval Greenfield wrote:

Wouldn't it be nice to add generators and iterators like we can do with lists?

for item in f() + g(): print(item)

No. Then every iterator would be expected to implement __add__, including all the ones already written. It would also clash with existing meanings of __add__ on some types, such as NumPy arrays. -- Greg

Reply

Sign in to reply online Use email software

anatoly techtonik

7:04 a.m.

On Thu, Feb 16, 2012 at 4:46 AM, Greg Ewing wrote:

On 16/02/12 05:20, Yuval Greenfield wrote:

...
Wouldn't it be nice to add generators and iterators like we can do with lists?

...
for item in f() + g(): print(item)

No. Then every iterator would be expected to implement __add__, including all the ones already written.

It would also clash with existing meanings of __add__ on some types, such as NumPy arrays.

Good example for Python Ideas FAQ. -- anatoly t.

Reply

Sign in to reply online Use email software

julien tayon

5:51 p.m.

...
It would also clash with existing meanings of __add__ on some types, such as NumPy arrays.

Good example for Python Ideas FAQ.

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

Reply

Sign in to reply online Use email software

4452

Age (days ago)

4453

Last active (days ago)

Download

8 comments

6 participants

tags

participants (6)

anatoly techtonik
Greg Ewing
Guido van Rossum
julien tayon
Terry Reedy
Yuval Greenfield