Comment on PEP-0238

[Terry Reedy]

"Donn Cave" <donn at u.washington.edu> wrote in message
news:9icndo$loe$1 at nntp6.u.washington.edu...
> Quoth Courageous <jkraska1 at san.rr.com>:
> ...
> | [Snip: Guido's plan]
> |
> | This seems to me to be reasonable. While backward compatibility
> | is important in computer languages, the real problem occurs when
> | changes are abrupt. And in any case, we always have older versions
> | of the interpreter around.
>
> Sure.  For me, it looks like older versions is all we're going to
> have around.  Python is getting too complicated, has always been
> too slow (mainly startup cost), and now it's going to start breaking
> existing code in a serious way, for the sake of notions that are
> very debatable.

In my perhaps overly long-winded post Saterday evening ("2.2+==3000?"), I
tried to make three points.

1. The proposed code-breaking change is unprecedented in several respects.

>  I'm not saying "play my way, or I'm taking my
> ball and going" - I think I see the handwriting on the wall one
> way or the other.  The present offense is probably a blessing in
> disguise, since 2.0/2.1 is probably a better place to stake it
> down than a couple of versions farther down the curve.

2. We should recognize 2.1 (or perhaps 2.2, exactly which to be discussed)
as the end of the decade-long series of
no-code-break-except-in-extreme-circumstance releases and designate it as
the stable (and possibly maintained) 'older' version that, it has been said
several times,  we would 'always have around' to run 'old' code (or new
code written by 'old' pythoneers who choose not to follow all the changes).
The release that intentionally breaks code should be given a new major
number.

> It's ironic, just recently my department has started to think about
> supporting Zope on our web servers.  Of course I have been pitching
> Python as the greatest thing since sliced bread for 7 or 8 years,
> but my colleague, our main web server expert, was interested for a
> while but gave up on it fairly quickly, and one of the criticisms he
> levelled against it was that a new release will break all your code.
> Not my experience at all,  but how he will laugh to hear about this one.

3. While no-code break has been the promise and actuality for the 1.X
series of releases (which includes 2.0 and 2.1, which were bumped up for
legal/political reasons), Guide also stated years ago that he would give
himself more freedom to break code in a new major series, and that the
first change might specifically be to change int/int semantics.

> And now, if I'm obliged to bring in these new versions of Python after
> all, it probably will be because of Zope.
>
> Donn Cave, donn at u.washington.edu

Terry J. Reedy