Booleans, integer division, backwards compatibility; where is Python going?

[Geoff Gerrietts]

Quoting Tim Peters (tim.one at comcast.net):
> [phil hunt, on language change]
> > ...
> > But is this changing going to be continual? Are the language
> > developers constantly going to tinker with the language, out of a
> > sense of fun? (Not that having fun is bad, it's just that I don't
> > want to code against a continually moving target).
> >
> > Is there a final destination in sight, which these changes are
> > leading to?
> 
> It's possible it's the same final destination that C, Fortran, Perl and Java
> (for examples) are approaching with their own never-ending changes, but, if
> so, I doubt we'll live long enough to celebrate arrival.  If you want a
> change-free language, you're best off looking for a dead or dying language.
> For example, Algol 60 hasn't changed in decades.  For that matter, Python
> 1.5.2 hasn't changed in years.  WRT any technology, you can jump off the
> train any time you like.  Unless you pick your exit point very carefully,
> though, you may end up alone in the middle of nowhere.

It's a little frightening to me how much this sounds like a threat.

I admire the changes made to the language over the last couple years,
and think of them as marked and pronounced improvements. I look
forward to 2.3 and 3.0.

I'm a little leery about the rate of change, though. It isn't too hard
to develop across versions these days, though it's harder than I
initially expected. I don't think I'm complaining yet, but I am
unsettled.

I'll just drop two thoughts into the discussion.

The first comes from some popular management-theory from a few years
ago -- might have been _Managing Change_ but it might have been
something else, I forget exactly. This book pointed out that human
nature responds better to one big, massive change than a dozen smaller
ones. That goes against what seems logically true, that the smaller
changes are easier to take. I guess the psychology, though, is that
the ambiguity and uncertainty caused by change has some constant
factor that is more disruptive than the actual change itself. One big
change, and people grapple with it and get back to "normal". With a
bunch of little changes, people are in a continual state of ambiguity.

I think the recommendation that comes from this principal is that any
change which breaks backward compatibility is worth a major version
number. You can disagree; I'm not arguing or complaining, just
suggesting a management approach.

The second is that I personally find little to admire in C++, but one
of the things I do admire is that Bjarne decided to take a couple
years off to let the compiler writers and application programmers
catch up. The result was a language that everyone more or less thought
they knew, a solid foundation for people to build on and move forward.

It may not have worked quite as well as it should have, because the
compilers available today vary pretty widely in implementation. But
there's some value to taking a day off.

I remember in the early days of Java, when 1.0 went to 1.1 and
everything broke, all the developers I was learning from expressed
disgust. That was the first big indicator that the Java's promise had
crossed fingers to some. To others it was a sign that Java was an
immature language.

I like the features. I like the ideas that drive the features. I have
nothing but respect for the python-dev crowd and the magnificent
language they've produced. I prefer programming in Python over all
other languages I know. I'm not trying to be critical. But I do think
the change-management strategy is flawed.

Thanks,
--G.

-- 
Geoff Gerrietts        <geoff at gerrietts dot net>
"Ordinarily he was insane, but he had lucid moments 
when he was merely stupid."        --Heinrich Heine