跨语言和跨编译器的那些坑（CPython vs IronPython）

代码是宝贵的，世界上最郁闷的事情，便是写好的代码，还要在另外的平台上重写一次，或是同时维护功能相同的两套代码。所以才需要跨平台。

不仅如此，比如有人会吐槽Python的原生解释器CPython跑得太慢，或想让Python在.NET或JAVA虚拟机上运行，便开发了IronPython和Jython这样的工具。

Jython我并不了解，就说说Irpy吧，开放源代码，并有动态语言运行时（DLR）加持，这样牛逼的代码焉有不看？！于是看了小一个礼拜，云里雾里，确实还是自己能力有限。

跨语言

回到之前“最郁闷的问题”，我写了一个功能不错的数据清洗类库，有Python和C#两个版本，数据清洗的流程是用xml定义的，之前这样设计，就是为了跨平台和语言。打个比方，当我设计好一个清洗流程后，就可以交给C#或者Python去执行了。听起来是不是很美好？

我很感慨Python的强大能力，通过元类，动态添加属性等特性，我把C#将近5000行的代码，被Python用300行不到的规模基本实现了。不少人可能会好奇这是怎么做到的。C#有麻烦的继承语法，而不同的类只是核心函数不同。而Py我只定义了核心函数，然后动态添加属性生成类，不少不需要实现的接口根本就不用关心，再加上Py本身比Linq还骚的生成器语法，这样压缩自然是情理之中。

然而，蛋疼的问题出现了。

因为两种语言都引用了第三方的html解析类库，分别是C#的HtmlAgilityPack，和Python的lxml, 然而两种类库对于XPath的解析是有细微区别的，如是否有form标签，导致能被C#解析的却不能被Py解析！真是日了狗了！

我准备写XPath的转换函数，然而发现这是个无底洞，不同的html都有细微区别。还有C#已经完善的自动登录功能，我却还需要在Python的海洋里查找对应的相似函数。

那怎么办呢？我讨厌同时维护两种语言的代码，那就放弃一边吧！

跨编译器

换在三年前，我肯定是放弃Python而去接着开发C#(我确实有类似处女座的强迫症，因噎废食)，但如今，我被py漂亮的语法和众多第三方包倾倒，明显优先支持Py。

我想到了IronPython，这是.NET平台下能够运行Python的一套引擎，能够很方便地让C#和Python集成。这下简单了吧？我用Python实现核心代码，再用C#包装到外部界面上，那么就同时满足了一切需求！

然而，蛋疼的问题接着出现。。。。

IronPython的性能还是不错的，甚至运行起来比CPython还快！但是，回到那个解析html的Python类库，让Iron去执行引用lxml的Python代码是会出错的。翻遍了国内外论坛，大致意思是lxml（包括scipy和numpy）为了速度考虑，都是c语言扩展，而ironpython是不支持c语言扩展的模块的，所以，ironpython下不能使用lxml!

呵呵。

强迫症再一次发作，。我能怎么做？给lxml写一个纯Python的版本？或是，去研究某个能够支持IronPython支持c语言扩展的工具？每个任务都不简单，理性告诉，耗在这件事情上没有意义。

跨平台的意义：折腾

这就是工程脆弱性，一旦某个接口对不上了，整个类库都没法使用了。即使是python这样的语言，在2和3两种版本之间都让人颇为头疼。纵然有IronPython这种微软官方支持的强大工具，也充其量只能为一个玩具。原因很简单，在不同的底层基础上实现完全相同的上层，这是非常有难度的，一点点细微的区别，就会导致上层行为上的巨大不同。比如Python的生成器语法，在IronPython上就有问题。报出的错误让人匪夷所思，根本不知道怎么修改。

做编译器的人，自然是手握重剑，哪里不对改哪里。但我们这些小白怎么办，还要去搬砖呢！

这也是开源的重要性，万不得已，还能够去修改源代码。也是“使用被反复验证的稳定工具”的重要性，不要去使用莫名其妙的编译器/工具，否则本来应该思考美好的算法，而现在却在错误代码的海洋中抓破脑袋。一些新技术非常不确定，甚至已经停止维护，把时间浪费在这些事情上不值得的。

这也是工程的痛苦，也是工程的美妙。做研究的人，写了几行公式完事了，做工程的人，却不得不思考各种细节，从综合成本和效率的角度去做，做工程的人如果也是偏执狂，那他早就死掉了。

结语

那我还能怎么做呢？那就先这样吧，数据抓取/清洗继续用C#，分析用Python，清晰的分割线，中间用“利万物而不争”的文本做存储，让它们亲密接触的事情，再放放吧。