充氣娃娃之戀

最近一個月看了不少電影，

• 色戒
• 練習曲
• 變形金剛
  
• 男孩不壞 Superbad
• C+偵探
• There will be blood
• The Eye: 美國版見鬼，本來要看 Cloverfield，但是 imdb 的時間表不太正確。
• 蜂電影 Bee Movie
• 誰才是導演 Clash of Egos／Sprængfarlig bombe : 丹麥片
• 充氣娃娃之戀 Lars and the Real Girl

很多是飛機上看的，其中 Superbad 和誰才是導演都很不錯，色戒、練習曲、變形金剛都不用說。There will be blood 評價兩極化，看之前要有心理準備，C+偵探的風格還挺有趣的， The Eye 放鬆心情看，還是能達到娛樂效果。
不過這裡我要推薦的是充氣娃娃之戀。
影片簡介很簡單:害羞內向的 Lars，向他的哥哥和大嫂介紹他的女友。見面之後，發現居然是一個充氣娃娃。而 Lars 卻完全把充氣娃娃當成真人一樣對待（把她當人看）。在這個純樸的小鎮上，大家會怎麼看待這件事情呢？
光是看到片名，大家聯想到的可能是下面這段（娶充氣娃娃為妻的日本人）

即使不往變態片的方向想，想像的大概也是類似男孩不壞、四十歲處男、Knocked up 或美國派這樣的內容。
實際上，這部片子是極為溫馨的片子，是一部傑作。我不是說美國派、四十歲處男、男孩不壞
這些不好，只是說這部片子走的是更加內斂而溫情的路線。
裡面不乏簡單卻又讓人驚豔、發人深省的台詞和情節，像是冰凍的腳（你要看電影）的那一段話，或者是把（相對）正常的嗜好 action figure、絨毛玩具、寵物等等，拿來和把充氣娃娃當真人相比。
某些的情境下，人們不也嚐嚐把感情寄託在寵物、玩偶上嗎？將他們擬人化嗎？不也常常對虛擬的小說、電影人物，媒體塑造出的偶像賦予情感嗎？我們有什麼理由說 Lars 是不正常的？
(雖然說也有很多文化會把迷戀偶像、漫畫、action figures視為怪胎，也有 crazy cat lady一詞)但電影裡更多的是沒有文字的場景，一個眼神、一個表情、一個動作，傳達出許多只能意會的感動和情感。
所以不要被片名誤導了，這是一部相當好的電影。

Read More

有關修改周蟒的動機

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 哪些算是「字母」。

Read More

Python MagicCodec 0.1(更新到 0.11)

這個是基於 PEP 263 弄的 python meta programming 小玩意。
包含兩個神奇編碼 zhpy 跟 PyLua。 MagicCodec 0.1 Download
(*更新 0.11)
安裝玩 MagicCodec 之後，下面這段會變成完全合法的 Python 程式

# encoding: zhpy_utf8
吼叫="啦啦啦"
印出 吼叫
執行 '印出 "再%s一次"%吼叫'

這個也是

# encoding: lua
i=10
function run(func) repeat func() until i==0 end
run(function () print("Hello!",i) i=i-1 end)

直接用 python 執行，或者用滑鼠點 xxx.py 就可以執行了。

MagicCodec 裡面包含的 zhpy 基於 zhpy 1.4，但是大量修改過了（幾乎全部改掉）。
有幾個修改的重點：

1. 直接用 re 來做 tokenizer。殺雞不用牛刀，原來的 zhpy 用 pyparsing 。雖然說 pyparsing 提供很方便的功能來分解字串，但是類似的功能直接參考 python bnf 用 re.sub 來做，反而更簡單。
2. 改掉許多重複的程式碼。原來 zhpy 有非常多的程式碼，重複好幾次。tw 的了一個函數，cn 的又寫一個函數。這樣維護起來很難。
3. zh_exec 的功能和 exec 不同。我將他改成了比較符合原來 exec 行為的程式碼。改完後，原來的 zhpy_commandline 會爛掉，但實際上，會爛掉反而是 exec 的正確行為。
4. 「執行 」我還是直接翻成 「exec zhpy.dec <<」，因為 zh_exec 是函數，跟指令 exec 的語法不同。
5. type(x) == type("") 這類， 改成 isinstance(x,str)
   

另外一個重要的不同是改以 source code encoding 導向，將 zhpy 視為 python 的一個 codec，而不是另外一個 python 的實做。所以有許多差異。

1. 用 MagicCodec 取代 zhpy_commandline，因為直接用 python xxx.py 就能執行了。而不用 zhpy xxx.py
   
2. 用 excepthook 取代 try_run。
3. 另外增加 PyOS_Readline hook，這樣 python 的命令列可以直接變成 zhpy 的命令列。所以取代原來執行 zhpy ，改用執行 python ，然後你 import zhpy.hooks;zhpy.hooks.setup_all() 就可以直接執行中文的程式碼。
4. python win 也行，用前面的 zhpy.hooks 就可以了。
5. idle 不行。因為 idel 是分離式的。如果你在 MagicCodec 的 __init__ 或者執行 idle 前執行 zhpy.hooks.setup_all()，就可以。
6. idle 編輯器讀取 zhpy codec 的程式碼會解碼。所以會有問題。(所以 MagicCodec 也不永遠比較好)
7. import 比較單純。原來 zhpy import hook 就不錯了。但是現在更好，因為不用修改， python 就能直接 import zhpy 的 module。原因很簡單，因為有 MagicCodec 之後的 zhpy 程式碼是合法的 python 程式碼。
   

但是還是有很多東西不行。
像是

# encoding: zhpy_utf8
吼叫="啦啦啦"
印出 吼叫
執行 '印出 "再%(吼叫)s一次"%locals()'

就會失敗，這個不難解決，只要用另外的 hook 包住 locals, globals, setattr, getattr 等。__dict__比較麻煩一點，這個是 mataclass 可以hook的。

---

更新(2008-02-28)：由於網友 tocer 的反應，找到了好幾個 bug。
我其實有好幾個 Ubuntu 的機器，不過之前太懶，所以都沒有測試過。
所以雖然有考慮到， Linux 應該會有的狀況，不過都是用「想的」。
我們都知道，寫程式這樣是不行的。一測之下，果然 bug 連連。
第一個問題是好幾個檔案的權限設定有問題，windows 下還好， linux 下一般使用者就出問題了。
第二點主要是 encoded file 的問題。裡面幾個 return，雖然我是用很保守的 hook 法，但至少要傳回一些東西吧！另外還有一個語意上面的 bug 就是了。就是因為我要用保守的方式，只 hook，真正原始 file 形式的 sys.stdout/sys.stderr。所以語意應該是
if type(f) !=file: return f
才對，而不是
if type(f)==file: return
至於為什麼原來在 cygwin 上可以跑？我就不清楚了。現在剛好我手上又變成沒有 cygwin 機器了。搞不好 0.11 在 cygwin 上變成不能跑。
不過不管怎麼樣，這裡只是 display hook 上面的問題而已。最多就是顯示出問題。

Ubuntu 上建議使用有顯示 UTF8 能力的 Terminal。

最後，Ubuntu 上錯誤顯示會失效，因為 sys.excepthook 已經被其他 package 搶走了。我用很保守的策略來搶 excepthook，所以別人搶了，我就讓給別人。當然，你可以設定為強迫 excepthook（看程式碼）。
所以 hello.py 的錯誤展示有點多餘。

另外，還有一點小改動就是不再像 0.1 那樣 hook zhpy_codec 的 decode，只 hook streamReader。

---

更新(2008-03-01):
zhpy 1.5 已經出了，我雖然還沒有仔細看，不過應該有一些有趣的進展。

Read More

Python converters and related

和 PEP 263 Metaprogramming/DSL 有關的 Resource。

Converters (to Python):

• PyLua: Lua to Python (in Chinese)(Download)
  
• Pym : Matlab to Python
• vb2Py: Visual Basic to Python
• java2python: java to Python
• LOLPython: LoL Style Language to Python
• c2py: C to Python
• zhpy: Chinese Python <-> Python
• hpy: Hebrew Python
• ctopy: C to Python
• PyLog: Prolog to Python
• Unholy: Ruby bytecode to Python bytecode
  

Converters (from Python)

• Pyjamas: Python to Javascript
• Pyrex: Python to C
• Cython: Next generation Pyrex
  
• Py2cmod: Python to C
• Shed Skin: Python To C++
• PyPy: RPython To C,Javascrip t, LLVM, JVM,CLI
• Epy: Python to Javascript
  

Integrating with other languages
and

• Py++
• PyInline

Implemetations

• hpython: Python implementation in Haskell (Not much)

• CLPython: Python implemented in Common Lisp

• IronPython

• Jython
  

Misc &Metaprogramming:

• Easy Extend: python metaprogramming
• Generator Tools: copy and picke generators.
• Logix: python metaprogramming
• Byteplay: play with bytecode
• Bytecodehacks:
• BytecodeAssembler:
• Ned Batchelder: parsing with python
• LanguageParsing : parsing with python
• Intelib: Lisp within C++
• Psyco
• Ruby style DSL: ASPN recipe
  

Read More

Mardi Gras 珠珠嘉年華 （下)

Trick or Treat
Mardis Gras 要珠珠靠的是親和感，萬聖節的「不給糖就搗蛋」又是另外一回事。雖然同樣能從小培養小孩要東西的能力，但焦點顯然放在另外一種面向。
有趣的是這個習俗主要是在英語國家流行，如美國、英國等等，是一種巧合嗎？
聖誕節的禮物又是要東西能力的第三種面向，因為理論上，小朋友要乖，聖誕老人才會把好的禮物給他。
所以綜合三者，小孩學會了用社會的秘密 Protocol、學會了不給糖就搗蛋、學會了表現好才有收穫這三件事，在節慶活動中潛移默化出小朋友全方位取得社會資源的能力。

Or Maybe Not
沒錯，理論上是乖的小朋友才能在聖誕節拿到禮物，但這是「理論上」。實際上，能夠拿到好的禮物的是有錢人的小朋友。這裡隱含的邏輯變成是，有錢的小孩比較乖，有錢有地位的小孩才是好小孩。
仔細想想， Mardi gras 拿到的珠珠和聖誕禮物的不同點在於，珠珠是幾乎沒有金錢價值的，很純粹的只是一種計分工具，很純粹的是一場遊戲，爭取虛榮的遊戲。而聖誕禮物是有很殘酷的金錢價值的。萬聖節的糖果，雖然不像是聖誕禮物那麼貴重，但至少是能夠吃的。
這裡告訴我們，表面上我們要用拿珠珠的方式，用社會上的協定，巧取福利、名聲、地位，但是一旦天黑，碰到真的可以吃的東西時，那就別管什麼吃相了，恐嚇豪奪就行了。
傳統上聖誕禮物的獲得方式「乖」，可以用來平衡另外兩項，但在資本社會的影響下微妙的改變了。現在的聖誕節只是再度肯定了前兩項巧取豪奪能力的意義，因為誰管你去年做了什麼，禮物好不好才代表乖不乖。

我們難道沒有嗎
我們社會裡還是有很多場合有類似搶珠珠的練習遊戲，比方看球賽的時候搶贈品，參觀展覽的時候搶贈品（以前變魔術幫忙展覽宣傳時，體會贈品真的是吸引人潮的利器）。
但這和 Mardi Gras 的搶珠珠又不太一樣，因為發贈品的人通常只有一兩個特定人，而 Mardi Gras 和萬聖節要多東西的精髓在於向為數不少的不特定人要求東西（但又不是乞討）。因為重點是，你將來是要向整個社會要東西。
我們文化中可以比擬的，就是過年的紅包習俗，但培養出來的「要東西」方式，以及「要東西」的對象就不太一樣了。
所以說，不同文化節慶活動，給小孩的暗示不一樣，訓練出來的人格特質，當然就會不一樣。

Read More