閱讀目錄
上節拾遺
變量的創建與id
例1:name = 'oldboy'
首先，當我們定義了一個變量name = ‘oldboy’的時候，在內存中其實是做了這樣一件事：
程序開辟了一塊內存空間，將‘oldboy’存儲進去，再讓變量名name指向‘oldboy’所在的內存地址。如下圖所示：
例2:兩個變量名一個值
提問：當我執行下面這段代碼的時候，程序是怎么處理的呢？
我們猜想會有兩種可能:
第一種情況:程序分別在內存中開辟了兩塊兒空間來存儲‘oldboy’這個值，並且讓name1和name2指向這兩個值。如下左圖
第二種情況:由於兩個值內容一致，所以程序只開辟一塊兒空間存儲‘oldboy’，並讓name1和name2只想着個值。如下右圖
提問：大家來猜測一下會是哪種情況？
其實上面的兩種猜想都是對的。正常情況下字符串在內存里就是如我們猜想的第一種情況一樣，每一次創建一個變量都會在內存中申請一塊兒空間。
但是，python認為一些“看起來像python標識符的字符”和小整數字在開發中是常用的，因此出於節省內存的角度思考，對於這部分字符串和數字做出了優化[-5,257)，python解釋器會由於要定義的新變量內容與之前定義過的變量內容相同而不讓這部分內容占用新的內存空間。
我們如何證明我們的想法呢？
python為我們提供了一個id()方法，可以查看一個變量的內存地址。
>>> name1 = 'oldboy' >>> name2 = 'oldboy' >>> name1_id = id(name1) >>> name2_id = id(name2) >>> print(name1_id,name2_id) (4459387232, 4459387232)
執行完這段代碼就基本驗證了我們的思想，由於‘oldboy’是一個簡單的字符串，因此python解釋器做了優化，內存里只有一個‘oldboy’，name1和name2都指向同一塊兒內存地址。
如果是長字符串呢？就米有優化機制啦！
>>> a = 'this is a very long sentence' >>> b = 'this is a very long sentence' >>> id(a) 4394464720 >>> id(b) 4394464640
對於[-5,257)范圍內的數字也有優化機制：
>>> a = 256 >>> b = 256 >>> id(a) 4297546112 >>> id(b) 4297546112 >>> a = -5 >>> b = -5 >>> id(a) 4297537760 >>> id(b) 4297537760
但是超過這個范圍可就不太行了：
>>> a=257 >>> b=257 >>> id(a) 4402490032 >>> id(b) 4403650768 >> a = -6 >>> b=-6 >>> id(a) 4402490032 >>> id(b) 4403650768
例3:一個變量名2個值
提問：如果像下面這樣寫自己的代碼，最終打印name會得到什么結果？
name = 'oldboy' name = 'alex' print(name)
我想大家的答案是一致的，name此時應該是‘alex’，當我們在程序中對變量進行重復賦值時，就是對一個變量進行修改.
代碼解讀：
程序先申請了一塊內存空間來存儲‘oldboy’，讓name變量名指向這塊內存空間
讀到name=‘alex’之后又申請了另一塊內存空間來存儲‘alex’，並讓原本指向‘oldboy’內存的鏈接斷開，讓name再指向‘alex’。
如下圖所示：
例4:變量的賦值與修改
提問：如果像下面這樣寫自己的代碼，最終打印name1和name2會分別得到什么結果？
name1 = 'oldboy' name2 = name1 name1 = 'alex' print(name1,name2)
這里大家就會產生一些爭論了，先執行一下給大家看。
要想知道上面問題的結果是為什么，首先要了解在內存中兩個變量的存儲情況。
從上面的示意圖中我們可以知道，當執行name2=name1這句話的時候，事實上是讓name2指向了‘oldboy’所在的內存地址。
修改name1的值，相當於斷開了name1到‘oldboy’的鏈接，重新建立name1和‘alex’之間的鏈接。在這個過程中，始終沒有影響到name2和‘oldboy‘之間的關系，因此name2還是‘oldboy’，而name1變成了‘alex’。
身份運算
二進制
首先，計算機一共就能做兩件事：計算和通信
那在講計算機之前，我們先來講一個故事，大家知道古時候的中國是如何通信的么？
假如，戰國時期兩個國家要打仗了，我們壘了城牆，每隔一段就有兵鎮守，現在有人來攻打我們了，然后我們是不是得通知其他人有人來打我們來了？怎么通知？
字符編碼
通過上一節講的二進制的知識，大家已經知道計算機只認識二進制，生活中的數字要想讓計算機理解就必須轉換成二進制。十進制到二進制的轉換只能解決計算機理解數字的問題，那么文字要怎么讓計算機理解呢？
於是我們就選擇了一種曲線救國的方式，既然數字可以轉換成十進制，我們只要想辦法把文字轉換成數字，這樣文字不就可以表示成二進制了么？
可是文字應該怎么轉換成數字呢？就是強制轉換
我們自己強行約定了一個表，把文字和數字對應上，這張表就相當於翻譯，我們可以拿着一個數字來對比對應表找到相應的文字，反之亦然。
ASCII碼
可以先讓學生看圖片，然后再介紹ascii碼
假如我們就已經有這么一張表了
ASCII（American Standard Code for Information Interchange，美國信息交換標准代碼）是基於拉丁字母的一套電腦編碼系統，主要用於顯示現代英語和其他西歐語言。它是現今最通用的單字節編碼系統，並等同於國際標准ISO/IEC 646。
由於計算機是美國人發明的，因此，最早只有127個字母被編碼到計算機里，也就是大小寫英文字母、數字和一些符號，這個編碼表被稱為ASCII編碼，比如大寫字母 A的編碼是65，小寫字母 z的編碼是122。后128個稱為擴展ASCII碼。
那現在我們就知道了上面的字母符號和數字對應的表是早就存在的。那么根據現在有的一些十進制，我們就可以轉換成二進制的編碼串。
比如
提問：假如我們要打印兩個空格一個對勾 寫作二進制就應該是 0011111011但是 但是問題來了，我們怎么知道從哪兒到哪兒是一個字符呢？
正是由於這些字符串長的長，短的短，寫在一起讓我們難以分清每一個字符的起止位置，所以聰明的人類就想出了一個解決辦法，既然一共就這255個字符，那最長的也不過是11111111八位，不如我們就把所有的二進制都轉換成8位的，不足的用0來替換。
這樣一來，剛剛的兩個空格一個對勾就寫作000000000000000011111011，讀取的時候只要每次讀8個字符就能知道每個字符的二進制值啦。
在這里，每一位0或者1所占的空間單位為bit(比特)，這是計算機中最小的表示單位
每8個bit組成一個字符，這是計算機中最小的存儲單位(畢竟你是沒有辦法存儲半個字符的)orz～
要不要舉例子說單位？就像我們形容長度會有厘米、分米、米之分，在計算機里也有自己的計量數據大小的單位
人民幣的例子：給了你好多錢，假如沒有萬-十萬
bit 位，計算機中最小的表示單位 8bit = 1bytes 字節，最小的存儲單位，1bytes縮寫為1B 1KB=1024B 1MB=1024KB 1GB=1024MB 1TB=1024GB 1PB=1024TB 1EB=1024PB 1ZB=1024EB 1YB=1024ZB 1BB=1024YB
提問：學完ascii碼，作為一個英文程序員來說，基本圓滿了。但是作為一個中國程序員，你是不是覺得少了點兒什么？（再給學生看一下ascii碼表）
GBK和GB2312
顯然，對於我們來說能在計算機中顯示中文字符是至關重要的，然而剛學習的ASCII表里連一個偏旁部首也沒有。所以我們還需要一張關於中文和數字對應的關系表。之前我們已經看到了，一個字節只能最多表示256個字符，要處理中文顯然一個字節是不夠的，所以我們需要采用兩個字節來表示，而且還不能和ASCII編碼沖突，所以，中國制定了GB2312編碼，用來把中文編進去。
你可以想得到的是，全世界有上百種語言，日本把日文編到Shift_JIS里，韓國把韓文編到Euc-kr里，
各國有各國的標准，就會不可避免地出現沖突，結果就是，在多語言混合的文本中，顯示出來會有亂碼。
Unicode
因此，Unicode應運而生。Unicode把所有語言都統一到一套編碼里，這樣就不會再有亂碼問題了。
Unicode標准也在不斷發展，但最常用的是用兩個字節表示一個字符（如果要用到非常偏僻的字符，就需要4個字節）。現代操作系統和大多數編程語言都直接支持Unicode。
現在，捋一捋ASCII編碼和Unicode編碼的區別：
ASCII編碼是1個字節，而Unicode編碼通常是2個字節。
字母A用ASCII編碼是十進制的65，二進制的01000001；
字符0用ASCII編碼是十進制的48，二進制的00110000；
漢字“中”已經超出了ASCII編碼的范圍，用Unicode編碼是十進制的20013，二進制的01001110 00101101。
你可以猜測，如果把ASCII編碼的A用Unicode編碼，只需要在前面補0就可以，因此，A的Unicode編碼是00000000 01000001。
新的問題又出現了：如果統一成Unicode編碼，亂碼問題從此消失了。但是，如果你寫的文本基本上全部是英文的話，用Unicode編碼比ASCII編碼需要多一倍的存儲空間，在存儲和傳輸上就十分不划算。
UTF-8
所以，本着節約的精神，又出現了把Unicode編碼轉化為“可變長編碼”的UTF-8編碼。UTF-8編碼把一個Unicode字符根據不同的數字大小編碼成1-6個字節，常用的英文字母被編碼成1個字節，漢字通常是3個字節，只有很生僻的字符才會被編碼成4-6個字節。如果你要傳輸的文本包含大量英文字符，用UTF-8編碼就能節省空間：
| 字符 | ASCII | Unicode | UTF-8 |
| A | 01000001 | 00000000 01000001 | 01000001 |
| 中 | x | 01001110 00101101 | 11100100 10111000 10101101 |
從上面的表格還可以發現，UTF-8編碼有一個額外的好處，就是ASCII編碼實際上可以被看成是UTF-8編碼的一部分，所以，大量只支持ASCII編碼的歷史遺留軟件可以在UTF-8編碼下繼續工作。
搞清楚了ASCII、Unicode和UTF-8的關系，我們就可以總結一下現在計算機系統通用的字符編碼工作方式：
在計算機內存中，統一使用Unicode編碼，當需要保存到硬盤或者需要傳輸的時候，就轉換為UTF-8編碼。
用記事本編輯的時候，從文件讀取的UTF-8字符被轉換為Unicode字符到內存里，編輯完成后，保存的時候再把Unicode轉換為UTF-8保存到文件。
文件存取編碼轉換圖
常用編碼介紹一覽表
| 編碼 | 制定時間 | 作用 | 所占字節數 |
| ASCII | 1967年 | 表示英語及西歐語言 | 8bit/1bytes |
| GB2312 | 1980年 | 國家簡體中文字符集，兼容ASCII | 2bytes |
| Unicode | 1991年 | 國際標准組織統一標准字符集 | 2bytes |
| GBK | 1995年 | GB2312的擴展字符集，支持繁體字，兼容GB2312 | 2bytes |
| UTF-8 | 1992年 | 不定長編碼 | 1-3bytes |
基本數據類型
不可變數據類型
數字&字符串
數字和字符串 ： http://www.cnblogs.com/Eva-J/articles/6898648.html
可變數據類型
列表
列 表 ： http://www.cnblogs.com/Eva-J/articles/6923824.html
元組
元 組 ：http://www.cnblogs.com/Eva-J/articles/6957073.html
字典
字 典 ：http://www.cnblogs.com/Eva-J/articles/6940054.html