今天寫程式，人為製造了乙個由淺拷貝引起的bug，有必要歸納一下。先附上源**：
class performancetest(object):
def__init__(self):
.......
self.basic_path_list=
.......
#這就是乙個生成基礎路徑名的函式，從26個字元中選擇五個字元加上『/'構成基礎路徑
def_get_basic_path_list(self，path_num):
.......
.......
.......
#這是乙個對用elementtree實現的xml樹進行測試的測試函式，首先需要的就是生成測試路徑列表
#建立一顆結點數目為test_num，滿child_num叉樹
defadd_performance_test(self,child_num,test_num):
.......
#mid_list=deepcopy(self.basic_path_list)
#path_list=deepcopy(self.basic_path_list)
mid_list=self.basic_path_list
path_list=self.basic_path_list
while len(path_list)for mid_path in mid_list:
for spath in self.basic_path_list:
path=mid_path+spath
if len(path_list)+len(child_list)>test_num:
path_list+=child_list[:test_num-len(path_list)]
break
else:
path_list+=child_list
mid_list=child_list
#接下來就是將path_list中所有元素新增到自己定義的xml樹中，**略
......
結果，我在執行add_performance_test（2,100）函式後發現，生成的xml檔案中目錄樹居然有9層。
100=1+2+4+8+16+32+37，應該是7層，卻生成了9層目錄，bug在**？
經過一段時間的除錯後，確信是self.basic_path_list值在執行過程中起了變化，這是絕對不應該的。後來回想起初學python時看到的關於淺拷貝和深拷貝的內容，恍然大悟。mid_list和path_list在賦值的時候均執行的是淺拷貝，path_list在迴圈中改變時，也改變了self.basic_path_list值。 找到了問題，在賦值時將淺拷貝替換為深拷貝，**就正常執行了。
這個錯誤給我敲響了警鐘，像這樣的bug**不會報錯，但根本得不到需要的結果。我仔細檢查了以前寫的**，還發現了幾處類似的淺拷貝，尤其是執行那些**可以得要預期結果，但為了保險起見，我還是將其均替換為深拷貝。
在最後摘錄一部分python核心程式設計中對於淺拷貝和深拷貝的描述，望以後寫程式時引以為戒。
序列型別的可以通過三種方式實現淺拷貝，淺拷貝也是預設的拷貝型別：（1）完全切片操作；（2）利用工廠函式，比如list()等；（3）使用copy模組中的copy（）函式。然而對於非容器型別沒有拷貝這這一說。
有幾點關於拷貝操作的警告。第一,非容器型別(比如數字,字串和其他"原子"型別的物件,像**,型別和xrange物件等)沒有深拷貝一說,淺拷貝是用完全切片操作來完成的.第二,如果元組變數只包含原子型別物件,對它的深拷貝將不會進行.
Python 淺拷貝與深拷貝
淺拷貝 構造方法或切片 做的是淺拷貝 即拷貝了最外層容器，副本中的元素是原容器中元素的引用 在 python 中，通過乙個物件向另外乙個物件賦值，實際僅僅是賦值了物件的引用，而非建立乙個物件並賦值。那如何真正拷貝物件呢？我們看一下兩種不同的拷貝方式。先從乙個示例看起 anndy anndy age ...
Python 淺拷貝與深拷貝
以下例項是使用 copy 模組的 copy.copy 淺拷貝 和 copy.deepcopy usr bin python coding utf 8 import copy a 1,2,3,4,a b 原始物件 b a 賦值，傳物件的引用 c copy.copy a 物件拷貝，淺拷貝 d copy....
python 深拷貝與淺拷貝
當乙個變數 的時候,約定為 指向位址的過程 如果copy.copy 拷貝的是元組,那麼它不會進行淺拷貝,僅僅是指向 因為元組是不可變資料型別,那麼意味著資料一定不能修改,因此用copy.copy的 時候它會自動判斷,是指向。如果,用copy.copy copy.deepcopy 對乙個全部是不可變型...