Reaping the Whirlwind

Wednesday， April 06， 2005

Reaping the Whirlwind(旋风到来)

 

距上次PyCon已经过去两周了，我上一篇文章也发表一周多了。很多有意思的事情都快到来了。周五我和妻子要去拉斯维加斯参加国际女性内衣展（International Lingerie Show）。这并不是那种内衣秀，而是一个贸易展。在那里店铺老板们收集新款产品然后下订单。实际上不管怎样都不会参加这个展览的，我会在酒店房间进行一天的正常工作，她则去展会溜达并为她的店面找寻中意且hot的新产品。我遇见唯一有意思的事情是有一年在ILS看见了Penn Jillette（Penn and Teller组合的成员）正和他的女友在察看一个sex swing。至少我认为那是他的女友。之所以说是“察看（checking out）”，我是指观察其构造，而非真的要用它，可别想歪了阿:)。

Python Eggs势头很好，但发展很缓慢。我发现有非常多的项目正层出不穷的涌现且挤占了我的业余时间，比如为“ 1.0a 0” 最小发布文档所准备好的PyProtocols的泛型函数，但愿代码是可用的。前些天我收到了David Mertz的一封e-mail，他计划写一篇关于泛型函数的IBM developerWorks的文章，而且也确实在推动一个对人们有指导意义的实际版本的发布。尽管对于他的文章我不知道能否做好及时的准备，我仍需要进行一点重构不等式的索引机制(indexing mechanism)的工作。埃，实际工作量也不小。我正尝试搞定它，使得在只做“==”比较时无需花费O(n^2)的注册时间的开销，理想的话我甚至还想将其它比较运算符的开销都降至O(n log n)数量级上。

只有在建立规则索引而非调用函数时才会产生这些开销，所以情况并不那么糟糕。但是不包括‘==’运算符，实际它是很普通的，特别是在我开始重构peak.web以使用泛型函数之后。在peak.web中，泛型函数用于将一个对象类型（或单个对象）与名字结合起来映射到方法、模版或其他用于维持或呈现一个URL中指定的子对象。这里包含了许多正被创建的“name == 'something'”规则，所以O(n^2)开始快速递增。对于‘==’运算符算法的开销为O(n^2)，这没什么说的。正因为在相同表达式上相同索引通常用于不等式比较才会有这种结果。所以我需要研究出一种方法将使用“==”增加规则所产生的开销变为O(1)，也就意味着增加n个规则其开销就是O(n)而不是O(n^2)。不管怎样，只要我完成了这个，再加上一些相关的API cleanups，我才会真正舒心地发布出来，David也会在他的文章中谈到这些。

提到文章，我刚刚得到了Dr. Dobb's Journal的"Algorithms(算法)"杂志的样刊。没错，我在Dr．Dobb杂志上发表了一篇文章。从个人角度讲这是不可思议的，因为10或15年以前要是在任何一个计算机杂志上发表文章我都会兴奋得不行了，更不要说权威性很高的DDJ了。但现在的情况是，全世界的出版物看起来相关性是非常之少，我在网上已经发表了如此多文章以至于连出版的仅有3页纸的文章似乎都无足轻重了。“要么发表，要么销声匿迹（Publish or perish）”，至少在计算机领域，这句话的意思是“发布到网上”，因为如果选择出版，那就等于你已经落后了几个月了。

看一看广告挺有意思的，再回过头来看看过去一段时间，那时候我编写专利软件，而开源仍是一个模糊的概念。我查看了大量资料并有了一定感触，“喔，人们仍在为那些东西付钱？即使这样他们就是有了代码也不能和任何人分享？”花钱买软件这个后来遇到了阻碍的主意现在看起来非常愚蠢。（要注意的是，我并不是说专利许可证一无是处，也不是说没有产品值得去购买。事实上我不是说没有在这坦率地说话。贸然地总结或解释我所说的是要承担后果的，因为我很快就要将公共文盲奖授予那些无法区分开我实际写的和他们阅读时所臆测的想法的人们。）

哦，说到突然冒出来的想法，现在很明确的是，Chandler将告别与我在Spike所设计的相类似的一个schema definition API。人们和当前基于XML的schema机制进行着一番较量，在PyCon上这方面的经验显然足以建立起一个共识（至少对于schema而言），那就是XML必然败下阵来并由简单的Python 类定义和属性所取代，就像任意一个其他的Python元数据框架和对象数据库映射所用到的一样。

我认为这正是一件好事，除了可以证明我关于XML将成为开发者应用上的桎梏的预言是正确之外，还意味着代码将变得越来越短小和简单。现在，打包加载器（parcel loader）实际上必须在XML上实现两种传递：首先载入schema，然后载入schema实例。所以，当所有schema在Python下实现而非XML时，整个传递就完成了，而且包含了启动时间负载。其次，Python定义schema的格式十分简洁，其不使用XML名字空间来实现与“import（导入）”等价的操作。因此编写和阅读起来都很容易，所编写代码总行数也减少很多。开发者也不必将他们的类分割到两个文件中，即一个在包含方法的.py文件，另一个在包含属性的XML文件中。

然而，这就意味着这段时间我要比平常更忙碌些，我得利用上为Spike构建的且与新API相适应的工具，这会有点难度，因为它需要与目前存在的其它Chandler整合在一起。而且我们也仅仅完成了schema definition API，还不包括schema events API之类的。所以它可能在整个体系结构中还不是很像Spike。但它允许没有活动数据库的情况下对Chandler对象进行单元测试，这也是促使我研究该方法的最初的动力。

埃，这么多要做的，时间还这么少。也许再过一周等我在拉斯维加斯的时候就会有机会发表一篇更长一点的文章，这是我一直想写的。

 

（原文链接网址：http://dirtsimple.org/2005/04/reaping-whirlwind.html）