> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4