跨语言和跨编译器的那些坑(CPython vs IronPython)

时间:2024-01-14 17:53:50

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

不仅如此,比如有人会吐槽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!

跨语言和跨编译器的那些坑(CPython vs IronPython)

呵呵。

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

跨平台的意义:折腾

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

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

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

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

结语

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