有關修改周蟒的動機

Posted by tjwei on 星期四, 2月 14, 2008 with 1 comment
gasolin 在他的回應中,有一段話:
但同時警覺到: 讓人寧願自己修改而不是發個 patch 給我們,也表示周蟒還有不足之處。
讓我覺得我需要稍微解釋一下我修改的動機。
拿 zhpy 當 MagicCodec 的一個模組,是目的。看到 zhpy 包含 pyparsing 之後,我就知道我必須要修改一下才能使用,因為 PyLua 裡面已經用到了 Ply ,再包一個 pyparsing 太重複了。
而且我知道 zhpy 的功能只需要 tokenizing 就夠了。所以一開始就準備把 pyparsing 去掉,換成標準的 regex。
當然將命令列換成 MagicCodec 是初衷,既然現在要刪掉 pyparsing,就順便把一些不要的功能刪除,然後把 Interactive interpreter 換成 PyOS_Readline hook , exception handling 換成 hook。
看了程式碼後,因為身為一個設計師的天性,自然會有很多意見,包含風格和功能性。其中風格主要是一些程式碼審美觀(程式碼重複),而功能性包括zh_exec 的功能性, 還有翻譯字典的編碼(utf8 str or unicode)。
有關風格和功能性的選擇上,帶有主觀的設計選擇成分,雖然說(依照定義)我認為我的選擇較好,但是我也可以理解別種想法的可能性。我也有一些「不好」的選擇,包含會用一些 python 2.5 才有的語法,在 python 3k 不向下相容之際,有點尷尬。但我的辯解是 python 3k 可以直接用中文當變數名稱(*), zhpy 在 python 3k 下本來功能性就有不同的目的,所以也不算太尷尬。
那為什麼不考慮 python 2.4 2.3 的使用者呢?一來 python 2.5/2.6 的壽命會很久(因為沒有 2.7),二來我認為除非付出現在 30 倍以上的努力(推廣和設計),中文程式設計不會真的有實際用途。在推出試驗機型 prototype 時,這些不是我需要關心的事情。
gasolin 寫 zhpy 的目的和想法顯然不同。而我的目標對象根本就不是 end user,這也就是我連 distutil setup 都不提供的原因。因為整個設計取向不同,所以我拿原來的 zhpy code 來 refactoring,而不是 直接利用。因此也談不上 patch 原來的 zhpy 的 code,因為修改後的 zhpy 和原來的 zhpy 本來就是為了不同目的的產物。
我要設計一台飛天車,拿一台量產的車子當基礎來修改,但不代表原來的量產車也要加上翅膀。


(*)理論上, python 2.x 不能用中文變數名,不完全算是 python 的問題,而是中文字到底哪些算是字母的問題。 python 2.x 是用 isalpha 和 isalnum 來判斷合法名稱的,而這些和 LC_CTYPE 有關。理論上,可以修改 glibc locale 設定的 LC_CTYPE或者用 vista 的 custom locale builder 來告訴 python 哪些算是「字母」。
Categories: