有關修改周蟒的動機
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 哪些算是「字母」。
而且我知道 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: python
1 意見:
magic codec 跟 zhpy 就像是 F1 雷諾車隊跟量產車的關係。
雷諾車廠的模式是這樣的: F1 賽車 (prototype) 通常都是最好的，但量產車 (zhpy) 也會從 F1 車的設計中取得改進，進而成為量產車的標準配備。
我寫這篇的主要目的其實只有一句話: 要是 F1 賽車能直接將這些功能包成 patch 丟給量產車最好了 ^_^Y (懶)。
有分歧的部份暫時不論，其他像是透過 encoding 直接用 python 執行 zhpy、或是直接使用 python interpreter 跑 zhpy 等功能，相信是所有 zhpy 使用者會想要的。
即使您 submit 的 patch 也許有些不適合直接合併進 zhpy，我也可以弄個 plugin 出來當作量產車的選配套件呀 XD
張貼留言