这是一篇为Lisp程序员写的Python简介（一些Python程序员告诉 我，这篇文章对他们学习Lisp也有帮助，尽管这不是我的本意）。基本上，Python可以看作一个拥有“传统”语法（Lisp社区称之为“中缀”或者 “m-lisp”语法）的Lisp方言。一个来自comp.lang.python的帖子说到“我一直不明白为什么LISP是一个不错的想法，直到我开始 玩上了Python”。Python支持除了（macros）之外的所有Lisp的关键特征，并且你不会太想念宏因为Python拥有求值，运算符重载，和正则表达式解析，所以一些（不是所有）宏的使用场景都被涵盖了。
我深入学习Python的原因是，我正在考虑把Russel & Norvig的人工智能教材配套的Lisp代码转化成Java代码。一些教师和学生想要Java代码，因为：
那是他们在其他课程中最熟悉的语言。
他们希望有图形应用程序（graphical applications）。
少数人想要能在浏览器中运行的applets。
一些人只是因为在他们可以投入的有限的上课时间内，不能习惯于Lisp的语法。
然而，我们编写Java版本的第一次尝试很不成功。Java太罗嗦了，并且书中的伪代码和java代码之间的差异太大。我环顾四周，寻找一种和书中伪代码相近的语言，并最终发现 Python是最接近的。此外，有了Jython，我可以定位于Java的JVM。
我的结论对于我的使用目的而言，Python是一个非常优秀的语言。它使用简单（交互式的，没有“编译-链接-加载-运行”循环），这点对于我的教学目的是很重要 的。虽然Python不满足被拼写为J-A-V-A的前提条件，但是Jython已经很接近了。对于没有其他语言经验的人而言，Python似乎比 Lisp更容易阅读。我开发的Python代码看起来比 Lisp代码更像书中（独立开发）的伪代码。这点是很重要的，因为一些同学抱怨说，他们在把书中的伪代码和网上的Lisp代码对应起来的过程中，有一段困难的时间（即使这个过程对Lisp程序员来说是显然的）。
从我的观点来看，Python的两个主要的缺点是：1）只有很少的编译时的错误分析（compile-time error analysis）和类型声明（type declaration），甚至比Lisp还少。2）运行时间比Lisp慢很多，通常相差10倍（有时100倍，有时1倍）。定性地说，Python和解 释型的Lisp的速度差不多，但是很明显地慢于编译型的Lisp。基于这个原因，对于那些（或者会逐渐变为）计算密集性的应用（除非你愿意把速度瓶颈部分 用c重写），我不会推荐使用Python。但是我的目的是面向教育的，而不是产品，所以速度不是问题。
Python 简介Python既可以看作一个实用（更好的库）版本的Scheme，也可以看作一个净化（没有了“$@&%”符号）版本的Perl。然而Perl的 哲学是TIMTIWTDI（there's more than one way to do it，即都种方法解决同意问题），Python试图提供一个最小子集，使得人们以同样的方式使用它（即TOOWTDI，there's only one way to do it，但是如果你努力尝试的话，通常会有多种方式去解决同一问题）。其中一个具有争议的Python特征是，用缩进层次代替begin/end或者花括 号，启发它的哲学思想是：因为这里没有括号，所以也就没有了因为如何放置括号而引起的风格战争（style wars）。有趣的是，Lisp在这点上有同样的哲学思想：每个人都用emacs去缩进代码，所以他们没有去争论缩进方式。拿到一个Lisp代码，对它进 行合理的缩进，删除行首的左括号（opening parens），以及与之匹配的闭括号（close parens），这样我们就得到看起来类似Python的程序。
Python有做出明智妥协的哲学思想，使得容易的事情更容易，并且不排除太多困难的事情。在我看来Python做的不错。简单的事情简单，困难的事情逐 渐困难，并且你甚至注意不到这种不一致。Lisp有做出较少妥协的思想：提供一个强大并且完全一致的核心。这让Lisp很难去学，因为你从一开始就操作在 一个较高的抽象层次上，而且你需要理解你正在做什么，而不是仅仅依靠感觉活着看起来漂亮。但是它同样意味着更容易为Lisp添加抽象层次和复杂 性；Lisp优化的目标是使得很困难的事情不太困难，而Python优化的目标是使得中等难度的事情更简单。