On Sun, Apr 4, 2010 at 7:20 PM, Masklinn wrote:

On 4 Apr 2010, at 18:58 , cool-RR wrote:

...

I'm still a bit confused by generators and generator expressions, but

what

...

about making a `generator.__add__` method, that'll act like `itertools.chain`?

What would the use case be,

I'm not sure I understand your question. The same use case as for `itertools,chain`: When you have several generators you want to iterate over, one after another. (True, it might be not as good when you have more than 2.)

and why couldn't you use itertools.chain or generator.send for that?

I could use `itertools.chain`, but why type so much? I think if you have two generators, g1 and g2, then it makes sense that g1 + g2 will be an iterator that goes over the elements of both of them. About `generator.send`, I don't understand how it's related. But I'm still new to this. Ram.

Guido van Rossum wrote:

On Sun, Apr 4, 2010 at 9:58 AM, cool-RR wrote:

...

I'm still a bit confused by generators and generator expressions, but what about making a `generator.__add__` method, that'll act like `itertools.chain`?

This gets proposed several times a year. We always shoot it down for the same reasons: iterators are an abstract API and we don't want to burden every iterator implementation with having to implement various operations.

I actually messed around with writing a FlexIter class once that wrapped an arbitrary iterator and mapped __add__ to itertools.chain, __mul__ to itertools.repeat and a few other things. It actually turned out to get really ugly, really fast, so I abandoned the idea. Making arbitrary iterators as easy to manipulate as lists is an appealing idea, but a lot harder than it sounds given the deliberately limited definition of the iterator protocol. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------