Changing the Division Operator -- PEP 238, rev 1.12

[Paul Boddie]

Guido van Rossum <guido at zope.com> wrote in message news:<mailman.996263475.24304.python-list at python.org>...
> Here's a new revision of PEP 238.  I've incorporated clarifications of
> issues that were brought up during the discussion of rev 1.10 -- from
> typos via rewording of ambiguous phrasing to the addition of new open
> issues.  I've decided not to go for the "quotient and ratio"
> terminology -- my rationale is in the PEP.

Having just scanned the version of the PEP referenced from the
mirrored www.python.org, I'd like to make a few comments. Of course,
I'm one of those people who criticised the proposal earlier, but not
for ideological reasons. ;-)

Firstly, I'd like the PEP to be more definite about when the new
semantics become the default/only semantics. Stating a version number
really isn't definite enough, since we've all seen a "bumping up" of a
version number in the relatively recent past. In the historical record
there are plenty of references to "Python 2.0" which should really
refer to the subsequently adopted name "Python 3000", and things could
become confusing should you decide to adopt the "3.0" label
prematurely for some reason in the future.

Secondly, I would suggest a *long* period of transition. Not only are
there going to be problems with programs which are still in use from
today, but there will also be problems with books, articles and
tutorials. At least make the time of "conversion" happen when it's
extremely unlikely that someone will walk into a bookstore and find
the current edition of "Learning Python", for example.

Thirdly, it would be good if you addressed some of the concerns about
type preservation more directly in the PEP. Some people are concerned
about their integers becoming floats or rationals by accident, thus
either losing precision or exploding their memory usage. It would be
nice if some reassuring words could be employed suggesting how this
might be avoided in practice.

You have my apologies if these issues have already been addressed and
included in some version of the PEP of which I am not currently aware.
However, this brings me to my final point...

I feel that most of the "noise" on this issue could have been avoided
had the intentions of the developers been communicated clearly from
the start. To see a patch for some radical new functionality being
issued against an upcoming release, with only scant justification for
its inclusion and little *evident* consideration for the damage
possible to existing code, is almost guaranteed to scare and anger
people.

I can see the benefits of making these changes in the context of a
numeric system overhaul, but what seemed to be communicated was, "This
is going to change because I never liked it in the first place and
can't bear to wake up every morning knowing that it's there." This
doesn't justify some of the comments made on the subject, but it does
justify the sense of alarm expressed by a number of people.

Paul