PEP 260: simplify xrange()

[Tim Peters]

[James Logajan]
> 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.

Is this a case when one shouldn't?  That is, is it a specific comment on PEP
260, or just a general venting <wink> here?

> 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.

OK.

> (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 year?

You can ask the C, C++, Fortran, Perl, COBOL (etc, etc) folks that too, but
I suspect it's a rhetorical question.  I wish you could ask the Java
committee, but they work in secret <wink>.

> Or worse: trying to rewrite their code "more elegantly" using all the
> latest gimmicks.

Use of new features isn't required by Guido, and neither is downloading new
releases.  If *you* waste your time doing that, we both know it's because
you can't resist <0.5 wink>.

> ...
> Speaking of "generators", I just want to say that I think that
> "generator" makes for lousy terminology.

A generator, umm, *generates* a sequence of values.  It's neither more
specific nor more general than that, so we're pretty much limited to vaguely
suggestive terms like "generator" and "iterator"; Python already used the
latter word for something else.  I'd be happy to call them pink flamingos.

> If I understand correctly, "generators" are coroutines

They're formally semi-coroutines; it's not symmetric.

> that have peer-to-peer synchronized messaging (synchronizing and
> communicating at the "yield" points).

Way too highfalutin' a view.  Think of a generator as a resumable function,
and you're not missing anything -- not even an implementation subtlety.
They *are* resumable functions.  A "yield" is just a "return", but with the
twist that the function can resume executing after the "yield" again.  If
you also think of ordinary call/return as a peer-to-peer etc etc, then I
suppose you're stuck with that view here too.

> To my mind, "generators" does not evoke that image at all.

Good, because that image was overblown beyond recognition <wink>.

>> although-it-would-be-impolite-to-ask-we-why-still-ship-a-directory-
>>     full-of-crufty-old-irix5-demos-in-the-std-library<wink>-ly

> Perhaps because the Irix community would be quite Irate if they were
> removed?

Doubt it:  the Irix5 library files haven't really been touched since 1993.
For several years we've also shipped an Irix6 library with all the same
stuff.  But I suppose releasing a new OS was a symptom of SGI picking on its
users too <wink>.