Evolving Python and PEP238

[David Bolen]

Paul Prescod <paulp at ActiveState.com> writes:

> I notice that people keep mentioning Python 1.5.2. That was a
> particularly popular release of Python and people seem not to care much
> about releases before that.

I don't think that's it.  I think that due to the length of time that
1.5.x was available that it simply became the prevalent installed base
version.  1.5.2 in particular seems to have hit the sweet spot in
terms of remaining unchanged for a significant period of time during
which Python usage was ramping up quickly - thus it became the version
most commonly in use.  Since most of the references to 1.5.2 are in
relation to backwards compatibility, it makes sense that the most
deployed version would be used.

> Now consider if Guido says: "I'm going to be changing a behaviour that
> was deprecated in 1.4 and has issued a warning since then. Any
> complaints?" Would anyone here complain? I doubt it. The offending
> feature would have been expunged from the collective consciousness so
> long ago that people would not even remember it.

And so?  That's not apples to apples, since here we're talking about
changing a feature in a commonly in use release today, not a release
that was already replaced many years ago.  And we're talking about
just introducing the warning for a short period (relative to the
longevity of 1.5.2) and not a warning that already existed.

And BTW, sure, if I was using 1.4 in my deployed base I'd be
complaining about the above hypothetical case just as much and for the
same reasons.

> So the backwards compatibility question is a function both of how severe
> the change is and *how quickly it is made*. 

Add on "and how big a deployed base is impacted", and I'd agree.

> Python is around 11 years old. If Guido had embarked on this PEP238 path
> 7 years ago, the backwards compatibility problem would also have been
> severe for the code created in the first 4 years but by now most people
> would not know or care about the fact that there was 3 or 4 year period
> where divisions had to be migrated over slowly. Today, the period of
> transition would be merely a mythical historical event like the Great
> Usenet Reorganization.

Maybe - or maybe these same arguments would have been held at the
time, albeit with a much smaller user population, which might have had
an easier time adapting.

This is no different than changing any other deployed system.  I have
a much easier time making changes in my system when it's still in
development on my desktop, to when I have one customer, to 10
customers, and so on.  By the time I have hundreds or thousands of
locations, changes by necessity have to take that into account.

Does that mean that the threshold for making a change (even if good on
its own merits) needs to take into account my deployed base.  You
betcha.  Does that mean there's a higher hurdle for justifying the
same change later in the development cycle than at the beginning.  Yes.

Does that mean you'd never make a backwards incompatible change?  No,
but it's far harder to justify when you've got a lot of systems out
there.

> It is one thing to argue that this change is not the right one. I
> disagree but we can cover that in another discussion.

And which, as I mentioned earlier, in the abstract I might agree, and
certainly wouldn't have minded if this was how division was defined
initially.

>                                                       It is another
> thing to say that Python is a language that can only accumulate warts
> and never remove them. I think that that is an unnecessarily defeatist
> attitude. The mechanism for making "big" changes is well-defined and
> entirely workable. It merely requires patience and a sense that Python's
> future is important enough to have a long-term plan.

I'm not saying that it's impossible to make changes or fix warts.  I
do however feel that the justification for making such a change needs
to be stronger the more impact to an installed base such a change has,
and as you pointed out above, dependent on the scale/impact of the
change, and the time factor.

Much of this debate is how various people weigh these factors in the
overall equation.  As a person who has to maintain a large distributed
system, I will naturally weigh backwards compatibility (particularly
for a change like this that will eventually just break old code - it's
not a forward evolution but a retroactive one) heavily.  When I
compare that against the benefit of fixing this wart, I don't see as
overall beneficial enough.

That may not match what others think - thus the rather extensive
"discussion" :-)

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/