跨語言和跨編譯器的那些坑（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，清晰的分割線，中間用「利萬物而不爭」的文本作存儲，讓它們親密接觸的事情，再放放吧。