[Python-Dev] number-sig anyone?

[Guido van Rossum]

> By "right" I mean that we can arrive at a long-term stable numeric
> model that will be accepted by both the Python community as a whole
> *and* by the decision makers who will vote thumbs up or down on
> adopting Python in their organizations.  One of the most vocal
> opponents to PEP 238 (I won't mention his name, but his initials are
> S.H. ;-) lamented loudly that he'd be a laughing stock in his
> company because of that "division thing".  He mentioned something
> about being a "right arse" I think.

I'm not so worried.  While many of the opponents tried to explain
their position by arguing that int division was "right", their real
worry was backwards compatibility.  PEP 238 represents the *only*
serious backwards incompatibility in the transition to a new numeric
model that I can imagine.  The transition plan that I hope to be
checking into PEP 238 deals with the fears of the opponents by putting
the sea change off until Python 3.0.

> By having a well-considered overall plan for Python's numeric
> behavior, if you have to make an incompatible change today, another
> next year and a third two years after that, you can point to the
> plan that shows people where you're headed, how you plan to get
> there, and how they can write their programs in the meantime so as
> to be as resilient as possible.  Without such a plan -- or with
> several potentially competing plans as you proposed -- every change
> proposed or made will simply fuel the fires of those people who
> dismiss Python because "it's unstable".  The funny thing is,
> Python's semantics changed so little for so long that by comparison
> the rate of change does seem pretty high, but it's still much better
> than many applications or application libraries (such as the
> relatively recent glibc upheaval or the API changes Gtk is
> undergoing now).  And let's not even mention the folks in Redmond...

Any additional serious incompatibilities will also be put off till
Python 3.0.  But I repeat, I don't expect any.  Let me review:

Int/long unification:

    - This "breaks" code that counts on the OverflowError.

    - This changes the meaning of left shift (the only operation that
      silently throws away bits rather than raising OverflowError).

    - This changes the meaning of octal and hex constants that set the
      sign bit in short integers -- 0xffffffff is currently a fancy
      way of writing -1 on a 32-bit machine, but after unification it
      will be the same as 0xffffffffL (i.e., 2**32-1).

    None of these is a big deal I think.

Rationals:

    - The introduction of a new rational type in itself doesn't break
      anything.

    - Making 1/2 return a rational instead of a float could break
      some things but not at the scale of PEP 238.

    - Making 0.5 be a rational instead of a float will break more;
      we'll have to discuss this.

    I should note that the inclusion of rationals in the new numeric
    model is far from certain.  There are potential problems with
    rationals that may require them to remain a separate type forever.

This is about the extent of the changes to the numeric model that I'm
contemplating; I don't think that the new numeric model should change
much else. (I don't care much for some of the details of PEP 228, but
I have to think more about it.)

In other words, while the plan isn't spelled out yet, the only
disruption is PEP 238.

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