【自學Python系列】Python 基礎 (字符串,整數,註釋)

好久好久了,一直沒有想寫東西的慾望,這忽然之間發現仍是想寫一些東西,就算對本身的學習過程的記錄。一方面一邊學習一邊記錄筆記和心得來督促本身,另外一方面就是想記錄下來給你們分享下,並不擅長寫做,因此有什麼地方寫的很差,但願各位看官能夠提出來並留言,我將加以改進。python

關於如何安裝我就不介紹了,官網很完整也很完善的安裝指南。關於Python的版本,個人建議學新就行了,目前能夠直接學Python3.less

關於初學者咱們使用什麼IDE比較好呢?ide

  • IDLE 自帶的命令式的黑屏,一次能夠輸入一行代碼,若是隻是測試一個理論或者概念,既快又方便。
  • Geany,主要是setting中將Compile(pythonPath -m py_compile %f),Execute(pythonPath "%f") 設置響應的命令格式在Set Build Commands Tab。
  • VSCode,主要將python插件安裝好,而後在經過setting配置將命令行和調試環境配置好。

這裏我就不舉例了,須要的夥伴能夠網上查下配置,或者留言我能夠將配置好的code發出來。函數

如今開始直接介紹python基礎,比較散的知識點,我以爲基礎嘛,總結出來只要知道如何使用就好。學習

變量,存儲一個值 -- 與變量相關聯的信息。 格式,不須要定義類型,不須要分號之類的來標識語句結束。python是使用行的縮進結構來標識代碼塊和函數塊的。測試

  • 變量的命名以字母和下劃線開頭,不能以數字開頭
  • 不能包含空格,能夠使用下劃線來分隔其中的單詞。
  • 不要使用保留關鍵字和自帶函數名做爲變來名,並且還有一些特殊用途的單詞,後續慢慢道來
  • 短,並且要有描述性 student_name
  • 慎用小寫字母l(L)和大寫字母O(o),很容易被看做1 和 0

字符串

字符串就是一系列字符。用引號括起的都是字符串,引號能夠是單/雙引號,也能夠嵌套。ui

test = 'This is test!'
test2 = "This is test2!"
test3 = "This is show 'test again'"
print(test)
print(test2)
print(test3)

修改字符串大小寫, title() 函數是將字符串以首字母大寫的方式顯示,不管是 ABc,abC,AbC,ABC 均可以直接轉換爲 Abcthis

  • upper() 所有轉換爲大寫
  • lower() 所有轉換爲小寫

python 使用(+)來合併字符串,這樣的方法稱拼接idea

使用製表符和換行符來添加空白spa

  • \t 製表符
  • \n 換行符
  • \n\t 回車換行到下一行,而且添加一個製表符。

刪除字符串空白

  • lstrip() 刪除左空白
  • rstrip() 刪除右空白
  • strip() 刪除兩側空白

數字

整數

python 可對整數執行 加 + 減 - 乘 * 除 / 運算

python 使用兩個乘號 ** 表示乘方運算

空格不影響python計算表達式的方式。

浮點數

python將帶小數點的數字都稱爲浮點數.

很大程度,使用浮點數時都無需考慮其行爲,python一般都會按照你的方式計算,可是結果包含的小數位數多是不肯定的:
全部語言都存在這樣的問題,沒有什麼可擔憂的

>>> 0.2 + 0.1
0.30000000000000004

在字符串中使用整數,須要顯式的指出但願將整數用字符串表示,調用函數 str() : 將非字符串值表示爲字符串。

關於除法在python 2/3 是有區別的,在2中結果爲1,不是3中的1.5

Python2中,整數除法的結果只包含整除,小數部分刪除,不是四捨五入,是直接刪除。因此在2中通常用浮點數來計算,這樣結果也是浮點數。

>>> 3/2
1

>>> 3.0/2
1.5

>>> 3/2.0
1.5

註釋

# 標識後面內容會被忽略

import this 執行後能夠看到優秀的「Python之禪」

>>> import this
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!
相關文章
相關標籤/搜索