python和basic差不多應(yīng)該是容易學(xué)，但是功能弱的語(yǔ)言
basic是好多人的年幼時(shí)的回憶了，gvbasic，gwbasic，qbaisc，各種版本把很多人帶入了快樂(lè)的世界里面。但是很多人都會(huì)用了一段時(shí)間basic之后就把它廢置了，因?yàn)橛X(jué)得除了能夠用來(lái)play，功能太少。即便是vb，也是功能不甚完善的，很多地方要依靠其他語(yǔ)言寫的組件和直接調(diào)用 api來(lái)完成功能。
而python由于粗看之下，也是那么的像玩具。而且那個(gè)交互式命令行給人帶來(lái)的教學(xué)語(yǔ)言的感覺(jué)更加加強(qiáng)了人們的想法。
但是python其實(shí)功能不能說(shuō)是弱，其實(shí)是非常強(qiáng)大。python內(nèi)置了重要的數(shù)據(jù)結(jié)構(gòu)和文件這些功能，而且包含了一個(gè)很大的標(biāo)準(zhǔn)庫(kù)，基本上涵蓋了從 GUI到數(shù)據(jù)庫(kù)到網(wǎng)絡(luò)種種功能上的要求。而且還有很多愛(ài)好者，公司企業(yè)為python寫第三方的庫(kù)，這些庫(kù)品種繁多，功能齊全。而且還能把其他語(yǔ)言的庫(kù)加以包裝給自己使用，直接用c這樣的語(yǔ)言了來(lái)寫擴(kuò)展的庫(kù)也是可以的。所以說(shuō)，python像basic一樣好學(xué)，但是功能卻要強(qiáng)大很多。
第二個(gè)常見(jiàn)看法是：
python速度很慢，只能用在很少的應(yīng)用場(chǎng)合對(duì)于習(xí)慣了匯編和C++這樣的語(yǔ)言的人，思維總是有一個(gè)慣性（包括我自己也經(jīng)歷了這么一個(gè)階段）。就是看文件大小是數(shù)字節(jié)的，任何運(yùn)行時(shí)的 overhead都是絕對(duì)不可以的。那么一看見(jiàn)python這樣的動(dòng)態(tài)語(yǔ)言，而且動(dòng)態(tài)得非常厲害的語(yǔ)言，怎么看怎么不順眼也是情理之中了。
關(guān)鍵的問(wèn)題首先是你是否需要省那么個(gè)100~200k的大小，現(xiàn)在的內(nèi)存，硬盤，網(wǎng)絡(luò)通信環(huán)境已經(jīng)不大在乎這么一點(diǎn)的空間了，所以大小不是問(wèn)題。關(guān)鍵的是運(yùn)行時(shí)間嗎？其實(shí)在很多場(chǎng)合下是不需要那么快的速度的，比如開(kāi)一個(gè)窗口，運(yùn)行如果延時(shí)100ms，你感覺(jué)得到嗎？
python還能夠把py文件進(jìn)行一些處理變成pyc文件，加速源文件的解釋執(zhí)行。像java的虛擬機(jī)中的just in time或者h(yuǎn)ot spot這樣的預(yù)先讀取，預(yù)先編譯的技術(shù)都能構(gòu)同等的用于python。
python還有一個(gè)非常大的好處就是能夠用C這樣的快速的語(yǔ)言寫擴(kuò)展模塊。在軟件中一般都是20%的代碼占據(jù)了80%的運(yùn)行時(shí)間。這樣你可以先用 benchmark這樣的工具看看軟件是否慢得無(wú)法忍受了，然后再用profiler查出問(wèn)題瓶頸在哪里，那么就可以把關(guān)鍵的代碼用C解決掉。這樣可以節(jié)省了開(kāi)發(fā)時(shí)間（大部分代碼用python寫，比C快），而且運(yùn)行速度也可以令人滿意。
所以說(shuō)，對(duì)于python的速度是不用多擔(dān)心的。但是為了客觀起見(jiàn)，python的卻是慢的，在python中什么都是對(duì)象，這個(gè)比java這樣的不那么純的OO語(yǔ)言，就要差一些了。
第三個(gè)常見(jiàn)問(wèn)題是：
由于python是動(dòng)態(tài)的，程序更加容易出錯(cuò)了有這個(gè)看法主要是認(rèn)為，因?yàn)閜ython是動(dòng)態(tài)的，所以缺乏靜態(tài)的類型檢查，那么程序中的錯(cuò)誤就很難發(fā)現(xiàn)了。設(shè)置可能說(shuō)沒(méi)有執(zhí)行到的塊的語(yǔ)法都沒(méi)有得到完全徹底的檢查。變量由于沒(méi)有聲明，所以容易產(chǎn)生誤寫的錯(cuò)誤。事情真這么糟糕嗎？
第一個(gè)缺乏類型檢查是說(shuō)一個(gè)函數(shù)有幾個(gè)參數(shù)，但是由于參數(shù)的類型是動(dòng)態(tài)確定的，所以沒(méi)有辦法在靜態(tài)的時(shí)候就檢查傳入的參數(shù)和參數(shù)表是否匹配了。問(wèn)題是你寫的函數(shù)一定要自己測(cè)試了，而且一旦出了問(wèn)題，你是非常容易找到出錯(cuò)的地方的。dynamic typing是那么靈活好用，多這么一點(diǎn)麻煩也是值得的。
第二個(gè)看法就是錯(cuò)誤的。在python中所有語(yǔ)法都得到了檢查的。即使是處在分支語(yǔ)句中。只是有可能你說(shuō)的是這樣的情況：
a = 1;
明明加了分號(hào)，怎么不說(shuō)我錯(cuò)了呢？其實(shí)分號(hào)是可以用的，用來(lái)格開(kāi)在一行中的不同語(yǔ)句。
還有可能是這樣的：
if a == 0:
??fsdfsdafsad
這個(gè)怪東西應(yīng)該是一個(gè)語(yǔ)法錯(cuò)誤吧。其實(shí)是未必。因?yàn)槌绦蜻\(yùn)行到這個(gè)的時(shí)候可能這個(gè)名字就綁定到了什么東西上了，未必就是錯(cuò)誤。它是符合語(yǔ)句的語(yǔ)法的。
第三個(gè)則不是那么回事了。在basic中，你引用一個(gè)沒(méi)有出現(xiàn)過(guò)的變量名。那么這個(gè)變量自動(dòng)被分配，而且得到初始化。這個(gè)就會(huì)出問(wèn)題了。而python中，你不能引用一個(gè)沒(méi)有綁定到對(duì)象上的名字，而
name = 0
這樣的語(yǔ)句就是一個(gè)聲明了。沒(méi)有什么問(wèn)題。
name = 0
nama = 1
這個(gè)總是問(wèn)題了吧。對(duì)于變量名的誤拼寫出現(xiàn)在賦值的情況的時(shí)候就會(huì)被通過(guò)，因?yàn)檎J(rèn)為是產(chǎn)生一個(gè)新的名稱綁定。那么這個(gè)也好找出來(lái)啊，必然是出現(xiàn)在賦值的情況下，比basic中的那種情況好多了
總體來(lái)說(shuō)是，dynamic的東西缺少一些靜態(tài)的檢查的卻是會(huì)使得錯(cuò)誤隱蔽一些。但是由于動(dòng)態(tài)帶來(lái)的調(diào)試上的方便（比如能夠一眼從出錯(cuò)信息中找到出錯(cuò)的行，以及調(diào)用流程）足以把副作用給抵消了。
希望通過(guò)我的一點(diǎn)解釋，能夠讓你消去疑惑，喜歡上python。