給自學者的Python教學(2) :兩種比較簡單的方式來執行Python程式碼

YC
6 min readOct 22, 2017

--

有想過寫了一串程式碼之後,應該要怎樣做才可以讓你寫的心血可以執行和測試嗎?是在隨便任何地方都可以寫程式碼嗎?
(在之後的文章,還是會看到一些平常很少會用到的「字詞」,如xx器,印出什麼,宣告什麼🤔,等等。別擔心,就算暫時你覺得怪異或不明所以,但在之後的文章,你會慢慢了解到這些詞彙在程式設計中的「位置」是什麼。)

給大家介紹執行Python的方法之前,我們要先認識一下IDE是什麼。

IDE全稱為整合開發環境(Integrated Development Environment),是一種可同時作為:

  1. 文字編輯器,以編寫程式碼。
  2. 編譯器,編譯並將程式碼打包程式。(想詳細了解編譯器是什麼,又在開發程式中扮演什麼角色,建議參考:維基百科的編譯器條目
  3. 甚至是設計程式使用者介面的工具,如Xcode(一個撰寫OSX,IOS程式的IDE)就是一個可以設計UI的IDE。

的程式。IDE可以說是一種強力的開發工具,但是IDE在開發程式過程中卻不是必須的。我們可以只透過使用文字介面(由terminal進入),甚至在記事本當中就可以進行程式開發,但過程可能就會多了一點步驟。當然,有好用又方便的東西可以幫助開發,我認為是值得去學習使用的。

現在來介紹常用的Python IDE

1.Python 內建的 IDLE 交互式介面

Python的交互式介面──也就是IDLE,是在前文安裝完Python後自帶的程式,他可以簡單地輸入指令後得到結果。當然,它是比較偏向簡單新手向的,不適合用來寫成完整的程式,但是用來練習的話,會是一個非常方便的工具。你可以把它當作是一個Playground,在上面試著任何你想實驗的東西,因為他會馬上顯示出結果或報錯。

例如在IDLE 中輸入 「I will be a good developer」:

Python馬上就會給你跳出一個紅色的警告,「SyntaxError: invalid syntax」是說「語法錯誤:無效的語法」。對!如前文所說,程式語言是有特定的語法,如果你不跟規則來下指令,Python就會好像聽到外星語一樣,不知道你想要他幹嘛。

試著再在IDLE 中輸入 「a = 3 + 4」後return,再輸入「a」後return:

現在就出現a的數值:7 這個答案。(同時,恭喜你完成人生第一行程式囉)可以看到,在IDLE上,我們不需要做額外的動作,就可以做一點簡單的練習了。

2.PyCharm CE

PyCharm CE是一款功能相當強大的IDE,你可以直接在PyCharm CE中創建Python文件、編寫與編譯,並馬上在console中顯示結果。

這是PyCharm CE的網頁,只要選擇你的電腦系統,再選Community版本下載就可以了。

要使用PyCharm CE可以先按「Create New Project」,選擇你要建立新專業資料夾的位置,再按Create就可以創建新的Python專案了。

在創建專案後,我們只需要按下command+N(MacOS)/alt+Insert(Windows)就會出現選單,再點選python file就可以創建新的py檔。

之後,我們就可以開始動手寫下我們第一個程式了!

來寫個Hello World吧!

我們先新創一個叫做HelloWorld的檔案。(記得要選python file來創建喔)
然後,我們在文字輸入區中,輸入:

print(“Hello World!”)

然後按右鍵選單中的run來運行程式。應該就會出現如下圖中的情況。

在下面我們就可以看到你事入電腦的文字Hello World!出現在螢幕了!

現在,你們已經會如何執行你的Python 程式碼了。
馬上,我們就會進入到學習程式語言語法與規則中。

等等!先別走!這裡還有專屬於Python 的彩蛋!

在交互式解釋器中,我們可以輸入 import this。然後Python就會印出 「Python 之詩」!這首詩的內容蘊含著Python語言的編程哲學。

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one — and preferably only one — obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let’s do more of those!

如果你覺得我的文章幫助到你,希望你也可以化讚為賞,加入 Liker ,再按下方的綠色拍手按鈕,為文章點讚!為作者增加收益,再回饋更多好文章!

--

--

YC
YC

Written by YC

提供更精確的技術內容為目標,另創立「程式愛好者」專頁。首席軟體工程師,專研後端技術、物件導向、軟體架構。

Responses (1)