PEP 260: simplify xrange()
malcolm at commsecure.com.au
Wed Jun 27 06:41:52 CEST 2001
On Tue, Jun 26, 2001 at 07:42:20PM -0700, James Logajan wrote:
> Design mistakes one has made do tend to weigh on one's soul (speaking from
> more than two decades of programming experience) so I understand the primal
> urge to correct them when one can, and even when one shouldn't. So although
> I'm quite annoyed by all these new-fangled gimmicks being added to the
> language (i.e. Python generators being added to solve California's power
> problems) I have no problem with xrange being fenced in. (I find the very
> existence of the PEP process somewhat unsettling; there are now thousands of
> programmers trying to use the language. Why burden them with insuring their
> programs remain compatible with yet-another-damn-set-of-proposals every
PEP-6 partly helps that. Plus, any changes that would involve backwards
compatibility get debated to death both here, on python-dev and on
> Or worse: trying to rewrite their code "more elegantly" using all the
> latest gimmicks.
Protecting programmers from poor time management is not an excuse to
stop improving the language. :-)
> Speaking of "generators", I just want to say that I think that "generator"
> makes for lousy terminology. If I understand correctly, "generators" are
> coroutines that have peer-to-peer synchronized messaging (synchronizing and
> communicating at the "yield" points). To my mind, "generators" does not
> evoke that image at all. Assuming I understand it in my early senility....
Each call to the function generates a new value (and I think that's how
I will teach generators to new programmers; not as peer-to-peer
synchronized coroutines :-) ). Each to their own, I suppose, but it
makes sense to me.
I'm not nearly as think as you confused I am!
More information about the Python-list