對Python動態(tài)語言進(jìn)行學(xué)習(xí)指導(dǎo)
有人說Python動態(tài)語言是一種解釋性的語言，但是這種說法是不正確的，其實(shí)Python語言是一種面向?qū)ο?、直譯式計(jì)算機(jī)程序設(shè)計(jì)語言，也是一種功能強(qiáng)大而完善的通用型語言，對于***次接觸編程的用戶，Python絕對是***選擇。
但是很多人都會用了一段時(shí)間basic之后就把它廢置了，因?yàn)橛X得除了能夠用來play，功能太少。即便是vb，也是功能不甚完善的，很多地方要依靠其他語言寫的組件和直接調(diào)用api來完成功能。而python由于粗看之下，也是那么的像玩具。而且那個(gè)交互式命令行給人帶來的教學(xué)語言的感覺更加加強(qiáng)了人們的想法。
但是Python其實(shí)功能不能說是弱，其實(shí)是非常強(qiáng)大。python內(nèi)置了重要的數(shù)據(jù)結(jié)構(gòu)和文件這些功能，而且包含了一個(gè)很大的標(biāo)準(zhǔn)庫，基本上涵蓋了從GUI到數(shù)據(jù)庫到網(wǎng)絡(luò)種種功能上的要求。
而且還有很多愛好者，公司企業(yè)為python寫第三方的庫，這些庫品種繁多，功能齊全。而且還能把其他語言的庫加以包裝給自己使用。直接用c這樣的語言了來寫擴(kuò)展的庫也是可以的。
所以說，python像basic一樣好學(xué)，但是功能卻要強(qiáng)大很多。python速度很慢，只能用在很少的應(yīng)用場合。對于習(xí)慣了匯編和C++這樣的語言的人，思維總是有一個(gè)慣性(包括我自己也經(jīng)歷了這么一個(gè)階段)。
就是看文件大小是數(shù)字節(jié)的，任何運(yùn)行時(shí)的overhead都是絕對不可以的。那么一看見python這樣的動態(tài)語言，而且動態(tài)得非常厲害的語言，怎么看怎么不順眼也是情理之中了。關(guān)鍵的問題首先是你是否需要省那么個(gè)100~200k的大小。
現(xiàn)在的內(nèi)存，硬盤，網(wǎng)絡(luò)通信環(huán)境已經(jīng)不大在乎這么一點(diǎn)的空間了，所以大小不是問題。關(guān)鍵的是運(yùn)行時(shí)間嗎?其實(shí)在很多場合下是不需要那么快的速度的，比如開一個(gè)窗口，運(yùn)行如果延時(shí)100ms，你感覺得到嗎?
python還能夠把py文件進(jìn)行一些處理變成pyc文件，加速源文件的解釋執(zhí)行。像java的虛擬機(jī)中的just in time或者h(yuǎn)ot spot這樣的預(yù)先讀取，預(yù)先編譯的技術(shù)都能構(gòu)同等的用于python。
Python動態(tài)語言還有一個(gè)非常大的好處就是能夠用C這樣的快速的語言寫擴(kuò)展模塊。在軟件中一般都是20%的代碼占據(jù)了80%的運(yùn)行時(shí)間。這樣你可以先用benchmark這樣的工具看看軟件是否慢得無法忍受了，然后再用profiler查出問題瓶頸在哪里，那么就可以把關(guān)鍵的代碼用C解決掉。
這樣可以節(jié)省了開發(fā)時(shí)間(大部分代碼用python寫，比C快)，而且運(yùn)行速度也可以令人滿意。所以說，對于python的速度是不用多擔(dān)心的。但是為了客觀起見，python的卻是慢的，在python中什么都是對象，這個(gè)比java這樣的不那么純的OO語言，就要差一些了。
有這個(gè)看法主要是認(rèn)為，因?yàn)?FONT size=+0>python是動態(tài)的，所以缺乏靜態(tài)的類型檢查，那么程序中的錯(cuò)誤就很難發(fā)現(xiàn)了。設(shè)置可能說沒有執(zhí)行到的塊的語法都沒有得到完全徹底的檢查。變量由于沒有聲明，所以容易產(chǎn)生誤寫的錯(cuò)誤。事情真這么糟糕嗎?
***個(gè)缺乏類型檢查是說一個(gè)函數(shù)有幾個(gè)參數(shù)，但是由于參數(shù)的類型是動態(tài)確定的，所以沒有辦法在靜態(tài)的時(shí)候就檢查傳入的參數(shù)和參數(shù)表是否匹配了。問題是你寫的函數(shù)一定要自己測試了。
而且一旦出了問題，你是非常容易找到出錯(cuò)的地方的。dynamic typing是那么靈活好用，多這么一點(diǎn)麻煩也是值得的。第二個(gè)看法就是錯(cuò)誤的。在python中所有語法都得到了檢查的。即使是處在分支語句中。只是有可能你說的是這樣的情況。
對于習(xí)慣了匯編和C++這樣的語言的人，思維總是有一個(gè)慣性(包括我自己也經(jīng)歷了這么一個(gè)階段)。就是看文件大小是數(shù)字節(jié)的，任何運(yùn)行時(shí)的overhead都是絕對不可以的。那么一看見python這樣的動態(tài)語言，而且動態(tài)得非常厲害的語言，怎么看怎么不順眼也是情理之中了。
關(guān)鍵的問題首先是你是否需要省那么個(gè)100~200k的大小，現(xiàn)在的內(nèi)存，硬盤，網(wǎng)絡(luò)通信環(huán)境已經(jīng)不大在乎這么一點(diǎn)的空間了，所以大小不是問題。關(guān)鍵的是運(yùn)行時(shí)間嗎?其實(shí)在很多場合下是不需要那么快的速度的，比如開一個(gè)窗口，運(yùn)行如果延時(shí)100ms，你感覺得到嗎?
Python動態(tài)語言還能夠把py文件進(jìn)行一些處理變成pyc文件，加速源文件的解釋執(zhí)行。像java的虛擬機(jī)中的just in time或者h(yuǎn)ot spot這樣的預(yù)先讀取，預(yù)先編譯的技術(shù)都能構(gòu)同等的用于python。
python還有一個(gè)非常大的好處就是能夠用C這樣的快速的語言寫擴(kuò)展模塊。在軟件中一般都是20%的代碼占據(jù)了80%的運(yùn)行時(shí)間。這樣你可以先用benchmark這樣的工具看看軟件是否慢得無法忍受了，然后再用profiler查出問題瓶頸在哪里，那么就可以把關(guān)鍵的代碼用C解決掉。這樣可以節(jié)省了開發(fā)時(shí)間(大部分代碼用python寫，比C快)，而且運(yùn)行速度也可以令人滿意。
【編輯推薦】
