It's Python

01:22上午 十月 30, 2008 in category Java by ingramchen

from: http://xkcd.com/353/

應工作需要,我也開始摸了一下 python,摸了一段時間... 嗯,還真好用。就稍微屁一下吧

使用 Python 最特別的體驗是: python 是由 sequence 和 dictionary 兩種資料結構所構成的語言。 arguments 是一個 dict,scoped variables/method 也是用 dict,連他的物件導向也是用 dict 兜出來的。而 sequence 的觀念則是混合在 string, tuple, foreach, list comprehension...等等之中。整個語言規則幾乎可以用 sequence 和 dict 去理解。簡單講,就是學習曲線低, 然後又有很高的延展性。light weight and powerful!

python 並沒像 ruby 那樣著了魔,處處講究 everything is object,我每次看到 ruby 的 3.times(...) 就很感冒。3 是數字,叫數字 "工作"... 這很違反我的直覺... python 比較沒這種煩惱,不過 python 有一些很基本的物件的性質 卻沒內建。 一個 list 的長度居然是 len(list) 而不是 list.len(),一個物件的字串形態居然是 str(myObj) 而不是 myObj.to_string()。str() 還可以用 cast 去理解,但是 len() 就真的不可原諒了。

除了 OOP, python 也提供 procedure 和 functional 兩種 paradigm,前者讓 python 可以做為一個 script 語言,後者提供了 語言高級應用的可能。functional 的功能沒有很多,不過我覺有 list comprehesion, map(), filter() 和 lambda 就很夠用了。 我之前玩了一陣子 Haskell,什麼 rfold, curry, tail recursive, monad ,blah blah 看的眼花瞭亂。那時我自己的結論跟大家差不多 ... 就是純 functional 語言永遠不會起來的。未來可見的方向是 -- 取其 functional 語言中的精華,予以簡化, 然後逐步納入主流的語言。以此檢驗 python 的過去歷史發展和現在的成果,就可了解它的發展方向是正確的。 python 提供三種 paradigm,語言功能相當的完備,不同的功能可以選用適合的 paradigm 來寫。大家朗朗上口的 "choose the right tool for the job",一個語言就可以滿足。

python 語言的可讀性高這就不廢話了。但是強制縮排這件事讓很多人不滿。寫一陣子 python 後,發現強制縮排的確是有道理, 可以簡化語法。但是!但是!我發現強制縮排的問題不是強制,而是縮排的規則。python 只要上下的縮排的字元數一樣,就算過關。 我想這原意是希望保留一些彈性... 可是,假如你是用 4 個空白縮排的,然後你 google 一下程式範例,比方說 google app engine 的範例 ,查到的縮排卻是兩個空白的,這時剪貼到你自己的程式中就囧大了,只好手動修修改改... 這種事實在是很煩,目前我查到的 IDE 也沒有一個功能 能夠自動修正這種問題的 (手動排版程式碼,這是20世紀的事啊!) python 一開始應該狠一點就強制一定只能用4個空白來縮排就好了, 也不要允許 tab 字元縮排,全世界統一,這樣事情就簡化更多。(真的很計較 "強制" 這種事的人,不管規則怎麼定的有彈性,理由多麼充足, 都不會買帳的)

python IDE 目前做最好的 pydev extension (要錢),有 auto import 和 code completion (比免費的強), rename 和 extract method 等最基本的 refactoring 也有提供,勉強算是跟得上 21 世紀啦。我目前也是寫寫100行內的小玩具而已, 還不大需要 IDE 來管理 code。未來有沒有嘗試大型 python 專案的機會呢?我覺得是很少的,因為不適合。 大型專案比較重要的還是支援、維護、人力...etc,script 語言目前還是無法跟 java/c++ 等相較

python 最最吸引我的並不是簡潔的語法,而是無數的 library。python 程式真的多到翻掉,尤其我是用 linux 的,linux 到處都是 python,ubuntu repository 裡目前有 800 個 python lib,只有一個爽字可形容。 用 windows 的 developer,可惜了,你的人生錯過了 python... 我的意思不是 windows 不能用 python , 而是沒那個環境和機會讓你多接觸。就像在台灣也能學英文,但跟直接住美國學還是差很多啊! 如果要選一個 script 語言來當工具的話,語言本身 ruby 和 python 各有千秋,跨平台性兩者都不錯,但是...龐大的 lib 就代表高生產力啊, 所以 python 成為我的選擇。

script 語言的魔咒是什麼? U.N.I.C.O.D.E ! 任何處理多國語言的程式,不管大小,目前就用 Java 寫吧, 靠 python 嗎? 2010 年我再看看堪不堪用吧! python 3k string 預設型別總算是 unicode 了,過沒多久也要 release 了。 但是別忘了還有無數的 python lib 要轉換到 python 3k 去啊。 python 目前的成功就是自己未來的絆腳石.... 但是再怎麼痛苦還是得快點轉換,因為 21 世紀還不能好好處理 unicode 是一件不可諒的事~~~~

另一個 python 的賣點就是 google app engine。免費的 google cloud host 平台,超夢幻的! 有 google 撐腰,上面提到的成本、維護、人力一些 python 缺乏的好像就不再是缺點了。 我學了一點 python 後,馬上就開始研究了一下.... 但... 目前的結論是 google app engine 是一個玩具引擎.... 不是因為它的功能少,不是因為它的 ORM 不能 join,不是因為它還不太穩定....。而是它不能進行 heavy task!! 一個 http request 限制在幾秒內一定要完成,沒完成就 error ,也沒有提供 backgroud job。 我堅信一個道理:

電腦產生的價值來自於大量的運算和分析

一開始也許做做小小應用可以吧,等到網站大了,你會想要開始分析和研究資料吧?每次分析都把資料從 app engine 全部 dump 下來嗎?當場囧掉 ! 或者你打算做圖學或 bio 之類上的應用,需要大量的數學運算,那...... 真的只能自求多福了。未來若 app engine 不提供進行 heavy task 的功能,那 app engine 上的 app 永遠也做不大 (因為無法提供有價值的事)。而它號稱的 scale 能力也將沒人會用到...... (還真諷刺啊)

啊... 還有一些想屁... 今天時間晚了,就到此為止吧。對了, python 的書,推薦 dive into python 這本,它是一本深入深出的好書 (我沒打錯字,這本是給有語言基礎的人看的)。

迴響[10]

迴響:

反正他們還是高掛著 app engine 還只是 preview release 啊~ XD

由...發表 ericsk on 十月 30, 2008 at 12:16 下午 CST #

@ericsk
amazon AWS 已經 GA release 了啊!而且沒有我說的問題。 amazon 真是要得!

google app engine 還有得追咧....
(不過我怕的是,app engine 的方向一開始就是錯的)

由...發表 ingramchen on 十月 30, 2008 at 12:23 下午 CST #

for example:
myList = [7, 'eleven']
myList.__len__()
myList.__str__()

由...發表 marr on 十一月 29, 2008 at 06:05 下午 CST #

@marr

設計成 __foo__() 的 method 就是不希望直接拿來用吧?

由...發表 ingramchen on 十一月 29, 2008 at 06:08 下午 CST #

special method 是方便語,倒不意含「不希望直接拿來用」,開發者想要 override 當然也歡迎。
可參考 http://diveintopython.org/object_oriented_framework/special_class_methods.html

由...發表 marr on 十一月 30, 2008 at 11:04 上午 CST #

@marr
你的意思我了解。
我的意思是 __foo__() 這類 method 是設計來 override, implement 的,而不是拿來用 (呼叫) 的。誰希望自己淺顯易懂的 python 程式中一堆 __foo__() 的 "呼叫" 呢?

我希望看到 list.len() 這樣直覺乾淨的程式碼,不是 len(list) ,也不是 list.__len__()

這樣的設計大概有些歷史原因吧?我也考察不到了。

由...發表 ingramchen on 十一月 30, 2008 at 11:55 上午 CST #

编码重排用vim
vG=就可以

由...發表 邱焜 on 十二月 26, 2008 at 06:58 下午 CST #

len(list)
這樣的設計就我的觀察是因為 generic programming paradigm
python 不只提供 procedure 和 functional 兩種 paradigm, 還有 object oriented 和 generic programming

正如 c++ 裡的 STL algorithm 一樣
可以把許多同性質可以 generic 的演算法抽出來

熟悉 c++ 的人就不會覺得 python 這設計有什麼奇怪, 但站在 OO 的觀點, 例如長期寫 Java 的人一看就會覺得不順眼

這樣的好處是(正如在c++裡的generic和template), 任何物件只要提供 __len__ 這個協定(method), 就可以套進 len() 裡去

由...發表 bear on 一月 22, 2009 at 11:46 上午 CST #

套在 len() 的目的是什麼?不就是希望大家好呼叫、程式簡潔、好實作嗎?

所以我們希望讓程式可以一行、很直覺的方式計算長度:

len(myObject)
myObject.len()

上面兩個都是一行就搞定,都蠻直覺的,而後者比較物件導向。

然後來看怎麼 implement。

len(myObject) 需要實作 magic method __len__
myObject.len() ..... 就是實作 .len()....

len(myObject) 實作面需要轉個彎,去做去記憶一個特別的 method。 .len() 就是直直接接一對一的對應。

anyway, 我比較好奇的事,如果 python 一開始就採用 .len() ,而不是 __len__ ,那麼有什麼現在套用 len() 寫的很漂亮,而用 myObject.len() 很難寫的東西

由...發表 ingramchen on 一月 22, 2009 at 12:15 下午 CST #

大概只有在使用 higher order function 才會感覺有差異。在尚未引入 list comprehension 之前,如果要求一堆 sequence 的長度總和:

A=['ingramchen', 'bear', 'marr', 'ericsk']
print sum(map(len, A))

如果是使用 len method 來做,
print sum(map(lambda x: x.len(), A))

這個求總和的工作也可以透過 reduce 來做,那麼兩者就又差不多了。

由...發表 Duncan on 十月 14, 2009 at 10:52 下午 CST #

發表迴響:
  • HTML 語法: 關閉