Changing the Division Operator -- PEP 238, rev 1.12

[Guido van Rossum]

paul at boddie.net (Paul Boddie) writes:

> 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.

I've added this to the PEP now:

    Q. When will Python 3.0 be released?

    A. We don't plan that long ahead, so we can't say for sure.  We
       want to allow at least two years for the transition.  If Python
       3.0 comes out sooner, we'll keep the 2.x line alive for
       backwards compatibility until at least two years from the
       release of Python 2.2.  In practice, you will be able to
       continue to use the Python 2.x line for several years after
       Python 3.0 is released, so you can take your time with the
       transition.  Sites are expected to have both Python 2.x and
       Python 3.x installed simultaneously.

> 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.

Unclear what the question would be and how to address it.  PEP 238
changes nothing except the behavior of /, which will return a float or
rational in Python 3.0.  I don't think I need to address this any
further.  If you're asking about the reworked numerical model, answers
about that don't belong in this PEP.  I don't think you need to worry,
by the way.

> 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.

Much of the initial communication was done by people who hadn't read
the PEP and misstated the plan (e.g. omitting the transitional period
or the separate int division operator).  Then others started
complaining about the poorly laid-out plan -- again without reading
the PEP.  Typical usenet style -- I don't know how we could have
avoided this.

> 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.

Again, you're acting on hearsay.  Had you tried or even just studied
the patch that I initially posted, you would have noticed that the
default semantics weren't changed by the patch.

> 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.

Words put in my mouth.

--Guido van Rossum (home page: http://www.python.org/~guido/)