2.2+ == 3000? (was Re: Comment on PEP-0238)

[Terry Reedy]

> (Hm.  For various reasons I'm very tempted to introduce 'yield' as a
> new keyword without warnings or future statements in Python 2.2, so
> maybe I should bite the bullet and add 'div' as well...)
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)

If so, I suggest that you really bite the bullet and admit/announce that
2.2 (or maybe the release after) is the beginning of  the long
feared/promised  "Python 2/Python 3000".

---
Some background (with dates left a bit fuzzy) for those who have not been
carefully reading clp for the last several years:

When I started, about five (six?) years ago during the 1.3-1.4 transition
(and until recently) one of the 'advertising points' for Python was (and
has been) code stability.  Improvements would add features without breaking
existing code (except in rare and limited circumstances and only with a
compensating gain in functionality).  "Adopt Python and maybe contribute
something back and we won't pull the rug out from under you by breaking
code with incompatible upgrades" was, I think it fair to say, the promise.
Not too many months ago, someone (Tim Peters I think) pointed out that
almost all code from 1.0 days still ran just fine in 2.0 .

Sometime later (maybe 4 years ago) the issue of integer division and newbie
confusion arose (possibly not for the first time), followed by some of the
same discussion as recently.  GvR said that he probably wished, in
retrospect, that he had defined the grammar differently.  But he promised
not to make code-breaking changes -- at least not during the 1.X series.

Ah, the caveat:  around the same time, GVR said that he hoped/planned to
cap the 1.X series at about 1.6 or 1.7 in 2000 or so, cease personal
involvement in bug fixing and any other maintainance, and spend a year
developing a new Python 2.  One goal would be to fix the type/class split.
One freedom he would allow himself would be to break old 1.X code more
readily.  In particular, we should expect that he would change int/int to
return a float, if he then still though that to be the better choice [as
indeed he now seems too].

About 2 years ago, the mythical future Python 2 was relabeled Python 3000.
I presume the reasons were some combination of pushing it farther off into
the future, satirizing (and one-upping) the MS 2000 namings, and allowing
more wiggle room in naming future releases in the current Python series.

Last August/September, after changing employers, GvR used the wiggle room
to rename (for legal/organizational rather than technical reasons) what
otherwise might have been 1.6 final (or possibly 1.6.1) as 2.0.  The
additional changes in 2.1 were relatively minor.  Some of us consequently
see 2.x as an extension of the 1.x series and thereby subject to the
no-gratuitous-codebreak rule/promise.

Two or three weeks ago, Guido cryptically noted that PEP-0238 had not
gotten much comment.  I mistakenly thought of this as a suggestion to spend
time doing so (which I then did), whereas it seems to have been a hint that
he had already decided to accept it, for the reason given years ago.  I
wish he had been clearer, and that I had asked for a clarification, so we
could have focused sooner on the details still undecided.
---

Conclusion: The proposed/planned change *is* unprecedented.  It does not
have a consensus of  support, and I believe a vote would go against.
Theoretical math and CS considerations are mixed if not against it.  It
will, I believe, break more lines of code than all other upgrades so far
put together.  It does not add any functionality whatsoever.  It hardly
adds to net clarity, and maybe detracts, depending on the reader and
balance of i/i->i versus i/i->f constructions used.  It makes Python less
intuitive for programmers coming to Python from languages, such as C, that
use the same syntax.  The reason for it is to cater to the expectations of
current-non-user, hoped-for new users who will not read the grammar,
manuals, or even the tutorials enough to change their expectations.  [Note,
for instance, that this consideration hardly entered the recent discussion
on syntax for generators.]  Finally, this change was defined years ago as
one that would only happen in a new series of Python releases.

So, let's recognize that the future of change is nearly upon us.  In
particular, recognize 2.2 (effectively 1.7 or so) as the end of the 1.x
series and label the next release, if it will contain the int div change,
(along with type system changes), as 3.0.  Then we can realistically
discuss transitional issues.

Terry J. Reedy