重拾 Perl

最近,我开始重新学习 Perl,尝试用 Perl 来完成日常的开发程序。

原因是前几天听第 27 期内核恐慌时,主持人提到了 Perl 6。然后吴涛说起 Perl 时,感情很复杂。我当时心想,我对 Perl 的感情也很复杂咯。首先是对今天的程序员来说,Perl 太原始了,与 Python 和 Ruby 等语言相比,更显古老。回想起来,自从我学习了这两种语言后,我就再没有正儿八经用 Perl 写过程序。而我真正有了属于自己的电脑,是在 2007 年,那个时候我正好开始学习 Python,之后就没有碰过 Perl。

而另一方面,Perl 又是我的启蒙导师。具体的科目不好形容,与 UNIX/Linux、开源等世界有关。在接触 Perl 之前,我对编程,还停留在 BASIC 语言、C/C++ 语言、Pascal 语言上面,对于脚本语言,我的理解只是 .bat。在当时的教科书上,获得的结论是编译型语言比解释型语言在执行上各种优秀,解释型语言只有在学习时才有优势。UNIX 世界繁荣的脚本语言与著名的 KISS 原则,我则一概不知。

记得我大概在高中的时候买过一本小册子,第一次让我接触了 Perl。小册子的内容是 FORTRAN、Pascal、C、Perl、PHP 这五种语言的诞生历史,正是我感兴趣的内容。FORTRAN 那一节看的我比较枯燥,Pascal 是参加 OI 的语言,我比较熟悉。C 我虽然没怎么入门,但也接触过,于是就一章一章的看下来了。Perl 的这一章,是 Larry Wall 写的历史,用女孩子的成长周期来形容每一个版本的 Perl,语言相当幽默风趣,浅显易懂,还有 Larry 在设计 Perl 时的心路历程。虽然我还没有读过一行 Perl 程序,但看完了这一章节,我对 Perl 有了极大的好感。我喜欢的,就是这种不羁的风格。务实、能用的思想,再加上一些宅男一样自娱自乐,不管旁人眼光的态度,让我十分痴迷。

后来,我在新华书店买到了一本《Perl 语言入门》,一本薄薄的小册子。虽说《Perl 编程语言》才是真正权威的教材,但我还是抱着试试水的想法,买了更薄、也更便宜的“小骆驼书”。事实证明,这对我来说是一个极端正确的选择——这本书实在是太棒了!哪怕到了十多年后的今天,我还是认为这本书是编程语言教材中的 No. 1!或许是这本书的作者们都是常年培训 Perl 的老师,他们讲起 Perl 来头头是道、语言风趣、深入浅出。虽然我在阅读的时候,手边没有一台电脑给我来实践,但随着阅读和书中的示例,我很容易的就理解了书中的内容。书中用虽然没有涵盖 Perl 的方方面面,但其中 Perl 的 20% 的内容,就可以解决 80% 的问题。同时,书本的内容引起了我的一些思考,以及计算机世界眼界的变化,带给我的影响是巨大的。

另外,之所以说先看“小骆驼书”是个极端正确的选择,是因为后来我出于对 Perl 的喜爱,还购买了更贵、也更厚重的“大骆驼书”,也就是《Perl 语言编程》。不知道是书的本来风格与我不合的原因,还是翻译水平的原因,我总是无法对这本书产生喜欢的情绪。到最后还是把它当成了 Perl 的 Reference Manual。

出于对于 Perl 的这种复杂的感情,当我听吴涛给没有接触过 Perl 的听众介绍说“Perl 是一种‘只写’的编程语言”的时候,我忽然想到了,我日常工作中要分析的数据,虽说我用 Ruby 和 Java 分别实现了相关版本,但时常又被告知需要其它方面的结果。与其这时候再来该程序,不如尝试用 Perl,来快速的写一些只写的脚本来工作?

于是我这个周末开始了尝试。因为已经很久没有碰 Perl 了,我只好找出了《Perl 语言入门》来,从头看起,然后通过运行示例程序,来恢复过去的知识。有了一点心得后,就马上尝试来写我日常需要的一个功能。现在我发现,Spreadsheet 这个模块很有用,用来分析我们系统导出的 Excel 表中的数据,可以比较方便的提取数据,而且写起来比 Java 上的 jxl 模块要简单方便的多。

只是时间长了,有些东西还是很生疏。比如我需要用到 switch 语句,就去搜索语法,得到的结果居然是 Perl 核心中没有 switch!然后有用其它技术来实现的,还有一些模块。确实是 Perl 的“怪”的体现。不过我还有时间,这个过程也很好玩就是了。

最后,对比起 Python 和 Ruby,我觉得 Perl 有更强烈的“顺手”这个特性。它没有很完美严格的“世界观”,不会执着于把一切都弄的很漂亮,它只是你手头的一件趁手的工具,甚至你用完了随意一丢也不怕摔坏。在 Perl 里,class 关键字可没有其它语言中这么方便。

惊人的 PyBlosxom

好像在 2007 年初那会我对 blog 刚刚开始感兴趣的时候,就听说过 Blosxom 了。它是个非常简洁的 blog 发布软件。其核心程序只有一个 cgi 文件,里面是 Perl 代码。它的功能也十分简陋,连最基本的评论功能都没有。而这些功能都使通过插件来完成的,页面的样式通过 flavours 来安装。我曾经在自己的共享空间里实验过,比较麻烦,不符合我的要求,于是我就没有再管它。

后来我在 blog 上写过一篇文章,提到过我安装 Blosxom 的事,之后 Zoom Quiet 给我留言,说他在用 PyBlosxom,是用 Python 语言写的 Blosxom,而且他的 blog 就是用 PyBlosxom 支持的。我去了他的 blog看了一下,功能上确实和 Blosxom 很像,但他的 flavour 设计的非常漂亮,不过也没有安装评论等插件。当时我对 Python 还没有什么兴趣,因此就没有再关注 PyBlosxom 程序。

今天我在配置 MoinMoin 的时候,想过用 MoinMoin 等 Python 程序来管理我的整个网站,blog 方面我自然就想起了 PyBlosxom。我去了它的网页上看了看,它的首页跟 Blosxom 没什么两样,不过它的文档让我很惊讶。这些文档完全已经 Python 化了,和其它 Python 工具的文档风格,以及 Python 自身的文档风格,完全统一了起来。我在实验用的主机上尝试安装了一下,同时参考了一下文档,结果 PyBlosxom 给我感觉变化很大,安装了程序文件之后会用一个脚本文件自动创建 instance,跟 MoinMoin 非常类似,帮你建立好了插件和 flavours 的目录,而配置的内容也被分离到单独的文件中去。不光是原始的 CGI,PyBlosxom 也支持了静态输出、WSGI 等发布运行模式了。同时,URL 等设计,都可以看出和原始的 Blosxom 有非常明显的不同,相当不错。

我在想,也许这就是社区的力量之一吧。与此相比,Blosxom 的网页在这几年中的基本上没有什么变化,还是原先那样的简陋,而它的文档系统也比较原始,更别提它的程序本身的安装和配置还是跟过去一样的原始与晦涩了。是什么原因造成了两者之间那么大的差异呢?我觉得关键就是社区。目前 Perl 社区虽然早已发展成熟,但不可避免的是社区本身的年龄过大,已经有了苍老的态势了。虽然 CPAN 为 Perler 们津津乐道,但要是想要自动安装一个包,它的命令行远不如 RubyGems 和 Python 的 setup-tools 方便。关于 Perl 的语法,我觉得也在一定程度上阻碍了社区化的进程,主要是它在维护方面不如 Python 等新兴语言程序来的方便。

总之,作为一个商业语言,有一个强健的公司对它维护才是正道,这时 VC 笑到最后的关键;而作为一个开源的语言,有一个稳定、有活力的社区才是关键。

MoinMoin Wiki

今天我终于成功的在自己的 VPS 上跑起了 MoinMoin。

我很早之前就想用 MoinMoin 了。我最早在虚拟主机上运行过 MediaWiki,感觉不错,不过我更希望使用 MoinMoin。首先 MoinMoin 是用 Python 写的,我比较熟悉;而 MediaWiki 用的 PHP 我实在是没有入门。如果我可以运行 MoinMoin,那么我就可以更好的操纵这个 Wiki。

第二点原因是我比较喜欢 MoinMoin 做出来的站点风格。MediaWiki 做出来的 WikiPedia 虽然不错,不过我更喜欢 MoinMoin 做出来的 WoodPecker。我几年前就从网上和 WoodPecker 的创始人之一 ZoomQuiet 有过交流,看到他在 WoodPecker 上的个人页面,我总是很羡慕那种“乱糟糟”的感觉。我比较喜欢这种看似杂乱无章的大杂烩,就像是高手的小纸条,外人看上去皱皱巴巴的,丝毫没有条理,但高手却可以马上从上面得到信息。MediaWiki 是为了写百科全书而开发的,版面很严谨。我曾经想把 MediaWiki 做的页面故意弄乱,结果失败了。

第三点也非常重要,就是 MoinMoin 支持访问控制。如果说 blog 是一个公告板,那么我希望我的私人 wiki 可以稍微私密一点。虽然不一定有多少人访问,但我总是想记点见不得人的东西什么的。我本来觉得 MediaWiki 应该挺成熟了,应该有这个功能,结果去官方网页上查,却看到人家直接就说 MediaWiki 是为了知识可以公开访问、编辑而开发的,访问控制?提都不用提!我直接心碎了。MoinMoin 才不管这一套,奔着实用主义去的。

过去我没有 VPS,只有和别人合租过虚拟主机。我没有 root 权限,因此想真正把 MoinMoin 装在服务器上很难。我倒是可以从命令行启动 server,可这又不是真正的安装在 server 上,和在本地运行的 MoinMoin 没什么两样,只能测试,无法实用。我从网上看到有成功的例子,可我自己来安装却怎么都不行。归根结底是我没有 root 权限,fcgi 也没法配置。几次下来直接把我给弄伤了,所以后来我有了 VPS 后还是装的 MediaWiki。

这次我换了新 VPS 后,考虑再三,还是把旧的 VPS 再续了一期的费,三个月不到 3 美元,我可以承受,而且我有些东西想实践一下,比如 Rails、Django 等。新的 VPS 是放网站的,我不想轻易装各种各样的东西来测试,因此就在旧的 VPS 上随便用了。昨天我试验了 Django 之后,今天我就打起了 MoinMoin 的主意。

我从网上找到了这篇文章,照着做了一次,才发现安装 MoinMoin 实在是简单,当然是在你有完全控制的前题下。我在中间遇到过一个小问题,不知道操纵了什么地方,等我再次启动 moin.fcgi 之后就发现页面居然提示我 502 错误。我找了半天错误,才发现我是用 sudo 执行的启动 spawn-fcgi 的脚本(我把命令写在 shell 脚本里了),这样根本不行。我在 root 账号下运行脚本就没问题了,我估计应该要把 sudo 写进脚本里才行,不过还没有测试。

现在有了 MoinMoin,我也在考虑是不是要把 wiki 系统换过来。MoinMoin 有上面的种种好处,但要用到 Python,效率是个问题,我的 256M 内存的 VPS不知道跑的畅不畅,这还要我观察一段时间再说。另一方面,MediaWiki 是 WikiPedia 的引擎,这已经可以证明了许多东西。我用了这么一段时间 MediaWiki,也算是有点熟了,而要用 MoinMoin 的话需要重新熟悉。还有就是 MoinMoin 的数据存储在文件系统里,与 MediaWiki 的数据库相比到底怎样,我还没有一个明确的结论,至少那些随即字符的 id 让我有些云里雾里,不好识别。不知道 WoodPecker 的数据是不是很乱?

10 分钟写一个 blog 系统

和很多人一样,我第一次听说 Ruby on Rails 的时候知道了“10 分钟内写一个 blog 系统”的视频。Rails 的创始人 David Heinemeier Hansson 边讲边做,七搞八搞,伴随着一声声 “whoops”,一个简单的 blog 就完成了。

我在看这段视频的时候,因为之前没有怎么搞过网络程序,因此可能没有感觉到什么革命般的震撼,但已经挺吃惊了。在当时的我看来 blog 是一个相当复杂的系统了,如果我学会了 Rails 是不是也可以在短时间内写一个 blog 呢?

那之后我有几次想学习 Rails,但一直没有成功。一方面我对 Ruby 还是一知半解。我有 Perl 和 Python 的基础,因此 Ruby 代码对我来说很简单;但同时 Perl 和 Python 的基础又阻碍我学习 Ruby,每次拿起镐头书,看了没几页我就厌烦了。Rails 也是,我可以按照书上的例子在本地上运行程序,但我当时很执着于把程序部署到远程服务器上。那时候我只有一个 Dreamhost 共享空间,后来有了一个 Site 5 的共享空间,在这种环境下一个新手部署 Rails 程序的困难可想而知。几次部署失败后,我就对 Rails 失去了耐心。

几次失败后,我依然十分像学好 Ruby 和 Rails。因为 Confreaks 的关系,我感觉 Ruby 社区非常活跃,而我没法参与进去,让我觉得挺遗憾的。不过我一直没有什么需求,因此也没有什么动力去学习 Rails。这也让我对 Rails 这种稍微有些大的框架有些恐惧的感觉。去年暑假我们要做的项目,我就用 web.py 这种超轻量级的框架而不是 Rails 这种中大型的框架。

这个学期我们软件工程课的学期项目要做一个网络程序,我正好趁着这个机会来把 Rails 重新拾起来。于是这次我扎扎实实的从头开始看《Agile Web Development with Rails》,当然一些基础的东西我扫一眼直接掠过,等到看到讲 MVC 的时候我已经比较清楚了这种网络程序框架的原理了。顺着理解了书上的例子程序后,一切顿时感觉豁然开朗了。不仅仅是 Rails,同类的框架都是有共性的。我之前也试过 Django,和 Rails 一样最后也是无疾而终。但这次理解了 Rails 之后,我感觉 Django 框架也十分明了了。

从我一开始听说 Rails 到现在已经过去了几年时间了,我对网络程序的了解也有了很大的变化,远不是当初的自己可以比的。blog 系统对我来说也早已失去了神秘感,不过是一堆面向用户的对数据库进行操作的借口罢了。给我一定的时间和耐心,写一个 blog 系统是很简单的。而像 Rails 这样的框架可以自动生成框架代码,写一个 blog 系统就更是迅速了。

后来我们根据投票,确定了用 web2py 而不是 Rails 来完成项目。我一开始把 web2py 错当成 web.py 了,觉得是很简单的系统,所以就没怎么在意。后来发现错误后我还一度很惊慌,等静下心来看文档之后菜发现原来 web2py 就是 Rails 的Python 移植。明白了 Rails 的原理后 web2py 就没有什么神秘感了。当然我觉得 web2py 的官方书 写的不如《Agile Web Development with Rails》易读,可能是个人习惯的原因。

按照 web2py 的官方书里的例子弄了一下,我发现用 web2py 写程序相当容易。有了设计之后,把数据库定义输入进去之后基本上程序的框架就有了。然后添加 controller 和 view,其实就是函数和调用,不知不觉中程序就出来了。当然这些只是最基本的功能,更高深的功能我还没有看到,不过都是以这些为基础的。

按照这种思路想了一下,我那时就有了用 web2py 来创建一个简单的 blog 系统的想法,算是验证自己的学习进度。之后又托了一段时间,刚刚我正好没事,就这么弄了一下,也就弄成了,差不多也就 10 到 20 分钟的功夫。当然这个 blog 系统和 WordPress 可没法比,Trackback 和 RSS 输出都没有添加,但 blog 的核心功能都有了。我没有做什么美化工作,目前看上去是这个样子的:

Simple blog

有了这个经验之后,我对于我们的学期项目比较有信心了。不过我对这种程序的未来的信心又减少了。本来我觉得 Rails 这种东西既然这么火,那一定相当了不得,不过弄懂了之后觉得也不过如此,它不会是一个值得深入进行科学研究的方向,那么未来究竟在哪里呢?

web2py 非 web.py

我彻底的晕菜了。

我们这学期的《软件工程2》课的学期项目是一个笔记发布与分享系统,我们组有 11 个人,分为 logic、db 和 UI 小组(其实就是 MVC 了)。我们在开始的讨论时主要确定了两个 web 框架,Rails 和 web2py,以便在第二次的小组会议上选择。

我之前用过 web.py 写过简单的团购网站聚合程序,觉得不难;之前也看过 Rails 的书,想学习 Rails,并且有一个网站计划,但并没有实际操作过,于是在会议上表示两者皆可。最终我们确定了是用 web2py 来开发。

今天我看了一下 web2py book,觉得与我在去年暑假里用的 web.py 差别非常巨大。web.py 的主程序在一个文件里就完成了,而 web2py 则更加复杂,MVC 之间分成不同的文件,规模堪比 Rails 了。

我越看越觉得不对劲——web.py 就算再怎么升级也不能在半年时间里变化这么大吧?于是就上网查了一下,结果让我感觉非常悲剧:我之前一直把 web.py 和 web2py 给当成了一个东西,丝毫没有两者之间有不同的自觉性。

早知道我就在小组会议上投 Rails 的票了,我在开会前一直在看官方的书,感觉写的挺清晰的,要学会不难。结果现在悔之已晚,小组回忆昨天就结束了,我只好开始学习一个新的不熟悉的框架。不过好在我是 logic 组的 coder,主要管 controller 部分,不是十分需要操心宏观的框架。等别人弄好框架和数据库之后我往里填写业务代码好了,这样还容易一点。

这样的好处是我有了学习新的框架的经验,就是压力稍微大了点。苦也! 🙁

校内状态更新有进展

不愧是水木的Linux版主,yegle直接用wget就能成功的修改了校内的状态。不过话说wget、curl这种看似不起眼的命令行工具还真是牛屄,man了一下yegle的代码里面wget的参数,感觉我过去只把wget当成一个下载软件只是大材小用了。

我测试了他的代码。刚开始的时候一直不能成功,后来经yegle在Twitter上指点后也成功了。只是不会更新“目前”的状态,而是修改的“目前”的上一条状态。换句话说,目前的状态显式“什么都没做”,但从个人主页上可以显式状态被修改的历史。

这已经相当程度的解决了问题了。我对用shell处理xml还不熟悉,不能做到一直在后台更新Twitter的消息,有待以后研究。或者再继续修改那个Python脚本。要么就干脆结合Python和Bash,也可以解决问题。

另外,关于上一篇文章中的问题,我昨天回家就给python-twitter发了issue,今天早上看到有人回复,原来从今年四月8日开始,Twitter就不在http header里面支持since参数了,真是很奇怪。另外,发芽网的半瓶墨水回复了我的邮件,给我了一篇“鼓励性”的邮件……

被Python字符串弄崩溃了

受发芽网上的一段“校内网发帖机”的启发,最近想修改那段代码,让它可以部分的实现Twitter状态和校内网同步。之所以说“部分的”是因为我不知道怎么样让它像Facebook的Twitter插件那样Twitter的消息发送完毕后几乎同时(相差不到10秒钟)把Facebook的状态一并更新。另外一点很惭愧,就是我对HTTP编程不熟悉,目前还找不初修改校内的状态要提交的代码,只能修改一下原来的代码,在写日志上面做文章。

就算这样,也还是遇到了不少问题。我目前的打算是像过去WordPress上用过的一个插件,名字大概叫twitter-post那样,总结一天的Twitter消息,成为一篇文章,发送到校内上去。我开始用的是python-twitter这个包,很方便的就能弄到Twitter的消息。不过在它的GetUserTimeline()方法的说明中说到里面有一个since参数,提交一个“HTTP-formatted time”,就可以获得从那个时间点以后的消息。我觉得它应该能让我获得前一整天的所有消息,虽然需要做点处理,删除今天的消息。但这个“HTTP-formatted time”我实在是不知道是什么东西。昨天下午几乎找遍了我能从网上找到的所有表示时间的格式,怎么测试,它都只给我默认的最近20条的消息。可笑的是,python-twitter的代码里有test可以运行,而里面测试since参数的用例里用得Twitter帐号居然总共才不到10条tweets,这样GetUserTime()返回了所有的tweets,当然都是他要的时间段的啦。没办法,我只好去它的Google Groups里发问,结果今天居然找不到我提交的帖子了,难道是开发者觉得我是捣乱的?!!

既然这样不行,只好退一步先把能获得的最近20条tweets一并发上去,先看看效果再花功夫自己来解析前一天的所有tweets。结果很快写出了代码,但测试的时候却不行了。那段代码,我在程序里输入什么样的文字都可以正常发送,但自己从Twitter那里获得的文字就无法发送。Python一点提示都没有。我不光试验了python-twitter API给出的结果,还自己抓取了Twitter给出的XML文件自己parse,得到的结果也无法发送。我让两个程序在提交前输出提交的字符自己来比对,基本上都是一种格式的。简直快疯掉了。

接下来该怎么办?我目前只想到:

  • 继续骚扰python-twitter,谁让他给出的测试用例中有问题呢?

  • 像那段发布“校内网发帖机”的半瓶墨水虚心请教。

  • 昨天晚上yegle在Twitter上对那段代码表示了兴趣,如果我没猜错的话,他应该就是某个BBS的Linux版版主之一,大概Python功力比我这种菜鸟强很多,说不定他能“一语惊醒梦中人”……

我目前的代码如下,它还不能工作。这个是我自己parse Twitter的XML版本,用python-twitter的版本前半部分简洁一些,不过差别不大,两者都有同样的问题。


#!/usr/bin/env python
# -*- coding: utf-8 -*-

from xml.dom import minidom

# 需要先运行wget http://twitter.com/statuses/user_timeline/liufeng.xml
tw_url = 'http://twitter.com/statuses/user_timeline/liufeng.xml'
xmldoc = minidom.parse('liufeng.xml')

status = xmldoc.firstChild
tweet = status.childNodes[1]

output = ""
count = 1
flag = 0
for tweet in status.childNodes:
    if flag == 1:
        created_at = tweet.childNodes[1].firstChild.toxml()
        text = tweet.childNodes[5].firstChild.toxml()
        output += str(count) + " " + text + " " + created_at + "\n"
        count += 1
        flag = 0
    else:
        flag = 1

import cookielib
import urllib2
import urllib
import time

cj = cookielib.CookieJar()
opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cj))
exheaders = [("User-Agent", "Mozilla/4.0 (compatible; MSIE 7.1; Windows NT 5.1; SV1)"),]
opener.addheaders = exheaders
url_login = 'http://xiaonei.com/Login.do'
body = (('email', '*******@gmail.com'), ('password', '*******'))
req1 = opener.open(url_login, urllib.urlencode(body))
print "Login should be successful.\n"

body = {'relative_optype':'publisher', 'blogControl':'1'}
url_post = 'http://blog.xiaonei.com/NewEntry.do'
title = '最近我(说了/做了/想了)什么 %s' % time.asctime()
#xt = text.encode('utf-8')
print output
output = output.encode('utf-8')
print " fucked\n\n" + output
body['title'] = title
body['body'] = output
req2 = opener.open(url_post, urllib.urlencode(body))

#print urllib.urlencode(body)

翻译Python历史:Python对动态类型的使用

This post a a Chinese translation of Guido van Rossums‘s article “Python’s Use of Dynamic Typing” on his blog named “The History of Python“.

原文地址:http://python-history.blogspot.com/2009/02/pythons-use-of-dynamic-typing.html

ABC和Python间一项重要的区别是类型系统的总体特点不同。ABC是静态类型语言,意味着ABC编译器分析程序中使用的类型并判断它们被正确的使用。如果不是,程序会被拒绝并无法运行。不像今天多数静态类型语言那样,ABC使用类型推断(像Haskell那样)而不是像你在C之类的语言中看到的显式的类型声明那样。相反的,Python是动态类型语言。Python编译器高兴的对程序中类型的使用不感兴趣,所有的类型检查都在运行的时候进行。

尽管这样看上去对于ABC是一种很大的远离,但它并不如你想象的那样不同。不像其它静态类型语言,ABC不是(不曾是?它在今天确实已经是纯历史了:-))仅仅依赖于静态类型检查来确保程序不崩溃,当所有的操作执行时,它有运行期的库来为它们再次检查参数类型。这样做是因为编译器健全的类型检查算法的一部分在最初的语言原型实现中并没有被实现。运行期的库在调式的时候同样有用,因为显式的运行期类型检查可以产生漂亮的错误信息(指向实现团队),而不是解释器毫不检查参数时就盲目的运行而引起的core dump。

然而,ABC在静态类型检查外同时拥有运行期类型检查的最重要的原因是它是交互式的。在交互会话时,用户输入的ABC指令和定义在输入完成后就马上执行。在交互会话时,有可能会生成一个数字变量,删除它,然后再重新把它创建(换句话说,生成另一个有相同值的变量)成字符串。在一个单一子程序中,让一个相同的变量名先成为数字然后成为字符串是一个静态类型错误,但在交互会话中强制在不同的输入的指令里做这种类型检查并不合理,因为偶然创建的名为x的数字变量后边永远不能再用x用作其它不同类型的变量了!所以作为妥协,ABC对全局变量用了动态类型检查,但对局部变量用静态类型检查。为了简化实现,局部变量也是动态检查的。

因此,从ABC的类型检查实现方案到Python的方案只有一小步──Python简单的完全去掉了编译期类型检查。这完全符合Python的”切角”哲学,原因是如此精简实现不会引起安全问题,因为所有类型错误都在运行期中他们引起Python解释器发生故障前被捕获。

然而,一旦你决定了使用动态类型就没有回头路了。ABC的内建操作小心设计以便参数的类型可以从操作中推导出来。例如,在表达式”x^y”里编译器会推导出变量x和y是字符串,表达式的结果也是。在Python中,这样的推导基本上不能实现。例如,表达式”x+y”可能是字符串连接、数字相加、或者执行用户重载的操作。