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)
--
http://mail.python.org/mailman/listinfo/python-list
