[Python-Dev] number-sig anyone?
email@example.com (Skip Montanaro)
Wed, 25 Jul 2001 23:05:42 -0500
Skip> Today I took a look at http://mail.python.org/mailman/listinfo and
Skip> could find no math-sig or number-sig mailing list. If Python's
Skip> number system is going to change in one or more backwards-
Skip> incompatible [ways] I think there may only be one chance to get it
Paul> That implies there is a "right". There isn't. There are just a
Paul> bunch of opinions. And I can't imagine that a SIG would lead to a
Paul> convergence of opinions because people come from such radically
Paul> different backgrounds. I would rather see a rational-sig,
Paul> float-division-sig, decimal-sig and so forth. Each could come up
Paul> with a "locally coherent" plan and Guido could pick and choose.
My operational definition of "right" in this context is perhaps different
than yours. I realize there is no obviously right numeric model. If there
was, most programming languages would use it and we wouldn't need bots like
Tim to help guide us through minefields like IEEE 754.
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.
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...