> >This is all semantics, probably, but I don't believe you can make a> >strong case that yield is an ill-chosen name.>> It's not ill chosen, just arbitrary. I would be just as happy with> 'rtn' or 'tsr' or any fanciful word that doesn't convey a _wrong_> meaning.
To me, it conveys the perfect meaning. All it takes is having the
right mindset. You yield in traffic; you let someone go along before
you and then continue on.. that's what generators are, perfectly.
Yes, only one definition of 'yield' fits Python's usage-- but that's
infinately better then "Like return, but different".
What happens if you have a second type of 'return-like' statement?
If someone is learning a language, they'll always run into keywords
and such that they do not understand. So they have to look them
up. No big deal. Afterwards, when they get the mindset of how to
think in them, it sticks-- they can then glance down and remember,
and /know/, what's going on.
It becomes again pseudocode-that-works: 'yield X' means, 'give
off X and let the control continue on its way, i'll be continued later'.
However, something like '...@return X' wouldn't accomplish the same
result, in my opinion. For some people it'll be too easy to just ignore
the punctuation and think 'return', when its very important that they
not think 'return' in this case. For others, it'll always catch their eyes
and make them pause and think-- which variant of return is this?
A new keyword in this instance is perfect: its totally different, and
seperate from the behavior of 'return', so someone can't just pass it
by with assumptions of 'return', and once they learn what it is, it sticks.