python提取个十百千位数字_14. Python整数相除的设计问题

本系列文章译自Python之父 Guido van Rossum 的系列博客“The History of Python”。这个博客系列对我们理解Python及其演变很有帮助，经Guido同意，在这里翻译推荐给大家，希望大家喜欢，也请大家多多指教！

---

Python 对整数相除的处理是一个早期失误导致严重后果的例子。

如之前博文所说，在开发 Python 时，我抛弃了 ABC 对数字的处理方法，比如说，在 ABC 中，如果两个整数相除，会返回一个精确的有理数，而在 Python 中，则会返回一个整数。

根据我的经验，ABC 使用有理数来处理整数相除的方法并不好。一个典型的例子是，一些常见场景中的简单运算（比如计算个税），却会计算小数点后数千位，无疑会让程序运行得非常慢。这个问题解决起来并不难，用户只需要加上代表不精确的 0 就可以了——但这个方案是反直觉的，而且这个问题对初学者来说很难 debug 。

因此，在 Python 中，我借用了 C 语言中的数字模型。在 C 语言中，有不同精度的整型与浮点数，我选择其中的长整型（至少32位）作为 Python 中的整型，而用双精度浮点数作为 Python 中的浮点数。同时，我还为 Python 增加了任意精度整型，并称之为“长整型”。

---

我犯的主要错误，是借鉴了一个在 C语言中很有意义，但对更高级的语言来说没有必要的原则，即在标准算术操作中，包括数字相除，返回结果必须与输入参数同类型。更糟糕的是，在开始时，为了让类型系统互相独立，我还引入了另一条错误的原则，即禁止不同类型的数字之间进行算术操作。

于是，在最初版本中，用户无法用整数与浮点数相加，甚至也不能用整型与长整型相加。Python 对外发布后，Tim Peters 很快就说服我，这是一个非常烂的设计。于是我开始支持不同类型数字间的算术操作，采用的是一个常用原则。比如说，整型与长整型之间的操作会把整型参数转换为长整型，并返回长整型结果，而整数与浮点数之间的操作会将整数转换为浮点数，返回结果也是浮点数。

---

不幸的是，错误已经造成了——整数相除只返回整数结果。可能有人会问，有这么严重吗？从当时的情况看，对这个问题的修复建议其实有很多反对意见，因为有些人可能觉得，了解整数相除返回整数算是某种学习编程语言的“通过仪式”。

因此，我需要解释一下，为什么我把它当做一个设计失误。

当我们在函数中进行算术计算（比如说，计算月相）时，有时会希望所用的参数是浮点数，但 Python 中没有类型声明，因此，函数调用者很有可能会使用整数作为参数。在静态语言，比如 C语言中，编译器会把参数强制转换为浮点数，但 Python 不会——于是整个算术过程都会使用整数，直到在与浮点数的混合计算中，又把结果改为浮点数。

除了除法，整数的算术行为与浮点数是一致的。比如说，1 + 1 等于 2，正如 1.0 + 1.0 等于 2.0。因此，用户可能很容易误以为他们不需要关心数字类型。而在除法中，整数相除的结果会默认返回整数，也就意味着可能在计算中引入很大的偏差。虽然用户可以将所有数字强制转换为浮点数进行计算，但这不仅无聊，而且并不增强代码的可读性和可维护性。况且，这样的话，可能在一些复杂参数条件下无法调用同样的算法（当然，这是非常特殊的情况）。

所有这些问题，都是因为 Python 不会自动将参数转换为声明的类型。当我们传递一个非法参数，比如说字符串，一般会很快发现问题，因为绝大多数操作符不支持字符串与数字混合操作；但如果我们传递的是一个整数，却往往会返回一个接近正确结果的值，这个问题就更严重了——我们很难 debug，甚至根本不会注意到这个问题。

（我最近就遇到过类似问题：我要画一个模拟时钟，因为整数相除问题，对时针位置的计算其实是错误的，但只有在一天中的特定时间点才会出现这个错误。）

---

要修复这个问题并不容易，主要是用户的大量代码实际上依赖于这一设计。

因此我引入了另一个除法操作符（//），另外也引入了一个可以正常使用除法的机制（from future import division），同时，为修改程序行为，并帮助大家进行切换，我还增加了一个命令行参数（-Qxxx）。

幸而，在 Python 3 中，正确地相除已经成为程序的默认行为了。

---

公众号：ReadingPython