Generators and their next() and send() methods

[Thomas Mlynarczyk]

alex23 schrieb:

> http://www.python.org/dev/peps/pep-0342/
> That links to the original proposal to extend the generator behaviour

After some searching, I found this as a remark in parentheses:

"Introducing a new method instead of overloading next() minimizes 
overhead for simple next() calls."

And also a (little) more detailed explanation. So, basically, allowing 
an argument for next() would have meant more overhead in the Python 
implementation. Still, I don't quite see why, as this could be detected 
at compile time, couldn't it?

On the other hand, if I understood correctly, I can use send(None) as an 
equivalent of next(). So, while I cannot have next(argument) instead of 
send(argument), I can have send(None) instead of next().

> At a guess, I'd expect a new method was chosen to provide semantic
> distinctness with the original behaviour. 

But the semantics would not have changed, they would only be "extended" 
and thus remain "compatible", wouldn't they?

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)