Language change (was RE: iterators (was: python-dev summary))

[Tim Peters]

[Donn Cave]
> ...
> Still, I think I wouldn't be in favor of a constitutional prohibition
> on new features.

Then, unlike Andrew's, your future may be a happy one <wink>.

> I can't say there's no room for Python to evolve, it feels too much
> like the people who a century ago were convinced that most everything
> of consequence was already known to science.

Good example:  nobody predicted any particular problem at the start due to
types and classes occupying distinct universes in Python (can only create a
class in Python, can only create a type in C).  In retrospect, that was
braindead.  Healing that split would be a *simplification* of the language,
although, ya, it would probably have some visible consequences.

> I would like to find the antidote for creeping featurism, though.
> For Python, I guess that antidote is the BDFL, as Tim Peters observed
> in another followup, and that works for me - it would be paradoxical
> to say Python is the perfect language but we can't trust its creator's
> judgement.  And since it's his baby anyway, who cares what we think.

Guido does!  But he doesn't have time to argue with 10,000 people on every
point, and (this won't be a surprise to grownups <wink>) sometimes he
couldn't even if he did have time:  Python isn't entirely the end result of
an objective deductive process.  Many of the best ideas were adopted simply
because they "felt like" a good idea at the time.  Sometimes that backfires.
But that's rare, and that's what makes Guido a better language designer than
his critics (including me, on the one occasion I disagreed with him <wink>).

> Yet the development environment around Python has changed in recent
> years, and I guess that's where we came in.

What changed is that moving to SourceForge multiplied the number of people
who *could* commit changes from one (Guido) to dozens (Guido's army of
mindless drones).  Most of the flurry of changes checked in for 2.0 were
things Guido wanted for years, but didn't have the personal bandwidth to do
all by himself.

> One thing I think would be worth some thought is a positive expression
> of what we're thinking when we say "no thanks".  I mean, opposition
> to features is the negative complement to a positive idea about Python,
> about its elegance and power the way it is.  We don't get that out as
> often or as articulately as maybe we could.

You know that we're heading towared 100 rejected patches on SoureForge?
That's heading on 100 ideas people wanted badly enough to actually do the
hard work of implementing them (and that's impressive!) -- but they got
tossed in the bit bucket anyway.  People who think the floodgates have
opened are simply wrong about that (although a couple years' worth of backed
up ideas got implemented quickly).  Here's the latest one Guido rejected:

http://sourceforge.net/patch/
    index.php?func=detailpatch&patch_id=103693&group_id=5470

That's for a tiny, fully backward-compatible change, and one that's been
asked for several times on c.l.py over the years.  If I were the submitter,
I would find Guido's rejection comment unconvincing.  A good mental exercise
is to think of some change you *like*, and dream up a rejection comment you
would be satisfied with -- but realizing that in the real world, it's not
going to end with "QED".

it-won't-end-with-"bugger-off"-either-but-that's-how-it-often-
    gets-read-ly y'rs  - tim