㈠ python 遍歷
a=[[1,2,3,4,-1],[21,23,34,45,1],[3,4,34,2,1]]
cl_num=-1
foriinrange(len(a)-1):
this_line=a[i][cl_num]
next_line=a[i+1][cl_num]
issame=(this_line==next_line)
ifissame:
print('第{0}行第{1}列與第{2}行第{1}列相等'.format(str(i),str(cl_num),str(i+1)))
else:
print('第{0}行第{1}列與第{2}行第{1}列不相等'.format(str(i),str(cl_num),str(i+1)))
#第0行第-1列與第1行第-1列不相等
#第1行第-1列與第2行第-1列相等
此為按你要求，比較相鄰行的最後一列的值。
下次去stackoverflow上查答案或提問吧。
㈡ python中的數據結構分析
1.Python數據結構篇
數據結構篇主要是閱讀[Problem Solving with Python](Welcome to Problem Solving with Algorithms and Data Structures) [該網址鏈接可能會比較慢]時寫下的閱讀記錄，當然，也結合了部分[演算法導論](Introction to Algorithms)
中的內容，此外還有不少wikipedia上的內容，所以內容比較多，可能有點雜亂。這部分主要是介紹了如何使用Python實現常用的一些數據結構，例
如堆棧、隊列、二叉樹等等，也有Python內置的數據結構性能的分析，同時還包括了搜索和排序(在演算法設計篇中會有更加詳細的介紹)的簡單總結。每篇文
章都有實現代碼，內容比較多，簡單演算法一般是大致介紹下思想及演算法流程，復雜的演算法會給出各種圖示和代碼實現詳細介紹。
**這一部分是下
面演算法設計篇的前篇，如果數據結構還不錯的可以直接看演算法設計篇，遇到問題可以回來看數據結構篇中的某個具體內容充電一下，我個人認為直接讀演算法設計篇比
較好，因為大家時間也都比較寶貴，如果你會來讀這些文章說明你肯定有一定基礎了，後面的演算法設計篇中更多的是思想，這里更多的是代碼而已，嘿嘿。**
(1)[搜索](Python Data Structures)
簡述順序查找和二分查找，詳述Hash查找(hash函數的設計以及如何避免沖突)
(2)[排序](Python Data Structures)
簡述各種排序演算法的思想以及它的圖示和實現
(3)[數據結構](Python Data Structures)
簡述Python內置數據結構的性能分析和實現常用的數據結構：棧、隊列和二叉堆
(4)[樹總結](Python Data Structures)
簡述二叉樹，詳述二叉搜索樹和AVL樹的思想和實現
2.Python演算法設計篇
演算法設計篇主要是閱讀[Python Algorithms: Mastering Basic Algorithms in the Python Language](Python Algorithms: Mastering Basic Algorithms in the Python Language)[**點擊鏈接可進入Springer免費下載原書電子版**]之後寫下的讀書總結，原書大部分內容結合了經典書籍[演算法導論](Introction to Algorithms)，
內容更加細致深入，主要是介紹了各種常用的演算法設計思想，以及如何使用Python高效巧妙地實現這些演算法，這里有別於前面的數據結構篇，部分演算法例如排
序就不會詳細介紹它的實現細節，而是側重於它內在的演算法思想。這部分使用了一些與數據結構有關的第三方模塊，因為這篇的重點是演算法的思想以及實現，所以並
沒有去重新實現每個數據結構，但是在介紹演算法的同時會分析Python內置數據結構以及第三方數據結構模塊的優缺點，也就意味著該篇比前面都要難不少，但
是我想我的介紹應該還算簡單明了，因為我用的都是比較朴實的語言，並沒有像演算法導論一樣列出一堆性質和定理，主要是對著某個問題一步步思考然後演算法就出來
了，嘿嘿，除此之外，裡面還有很多關於python開發的內容，精彩真的不容錯過！
這里每篇文章都有實現代碼，但是代碼我一般都不會分
析，更多地是分析演算法思想，所以內容都比較多，即便如此也沒有包括原書對應章節的所有內容，因為內容實在太豐富了，所以我只是選擇經典的演算法實例來介紹算
法核心思想，除此之外，還有不少內容是原書沒有的，部分是來自演算法導論，部分是來自我自己的感悟，嘻嘻。該篇對於大神們來說是小菜，請一笑而過，對於菜鳥
們來說可能有點難啃，所以最適合的是和我水平差不多的，對各個演算法都有所了解但是理解還不算深刻的半桶水的程序猿，嘿嘿。
本篇的順序按照原書[Python Algorithms: Mastering Basic Algorithms in the Python Language](Python Algorithms: Mastering Basic Algorithms in the Python Language)的章節來安排的(章節標題部分相同部分不同喲)，為了節省時間以及保持原著的原滋原味，部分內容(一般是比較難以翻譯和理解的內容)直接摘自原著英文內容。
**1.
你也許覺得很多內容你都知道嘛，沒有看的必要，其實如果是我的話我也會這么想，但是如果只是歸納一個演算法有哪些步驟，那這個總結也就沒有意義了，我覺得這
個總結的亮點在於想辦法說清楚一個演算法是怎麼想出來的，有哪些需要注意的，如何進行優化的等等，採用問答式的方式讓讀者和我一起來想出某個問題的解，每篇
文章之後都還有一兩道小題練手喲**
**2.你也許還會說演算法導論不是既權威又全面么，基本上每個演算法都還有詳細的證明呢，讀演算法導論豈
不更好些，當然，你如果想讀演算法導論的話我不攔著你，讀完了感覺自己整個人都不好了別怪小弟沒有提醒你喲，嘻嘻嘻，左一個性質右一個定理實在不適合演算法科
普的啦，沒有多少人能夠堅持讀完的。但是碼農與蛇的故事內容不多喲，呵呵呵**
**3.如果你細讀本系列的話我保證你會有不少收獲的，需要看演算法導論哪個部分的地方我會給出提示的，嘿嘿。溫馨提示，前面三節內容都是介紹基礎知識，所以精彩內容從第4節開始喲，么么噠 O(∩_∩)O~**
(1)[Python Algorithms - C1 Introction](Python Algorithms)
本節主要是對原書中的內容做些簡單介紹，說明演算法的重要性以及各章節的內容概要。
(2)[Python Algorithms - C2 The basics](Python Algorithms)
**本節主要介紹了三個內容：演算法漸近運行時間的表示方法、六條演算法性能評估的經驗以及Python中樹和圖的實現方式。**
(3)[Python Algorithms - C3 Counting 101](Python Algorithms)
原書主要介紹了一些基礎數學，例如排列組合以及遞歸循環等，但是本節只重點介紹計算演算法的運行時間的三種方法
(4)[Python Algorithms - C4 Inction and Recursion and Rection](Python Algorithms)
**本節主要介紹演算法設計的三個核心知識：Inction(推導)、Recursion(遞歸)和Rection(規約)，這是原書的重點和難點部分**
(5)[Python Algorithms - C5 Traversal](Python Algorithms)
**本節主要介紹圖的遍歷演算法BFS和DFS，以及對拓撲排序的另一種解法和尋找圖的(強)連通分量的演算法**
(6)[Python Algorithms - C6 Divide and Combine and Conquer](Python Algorithms)
**本節主要介紹分治法策略，提到了樹形問題的平衡性以及基於分治策略的排序演算法**
(7)[Python Algorithms - C7 Greedy](Python Algorithms)
**本節主要通過幾個例子來介紹貪心策略，主要包括背包問題、哈夫曼編碼和最小生成樹等等**
(8)[Python Algorithms - C8 Dynamic Programming](Python Algorithms)
**本節主要結合一些經典的動規問題介紹動態規劃的備忘錄法和迭代法這兩種實現方式，並對這兩種方式進行對比**
(9)[Python Algorithms - C9 Graphs](Python Algorithms)
**本節主要介紹圖演算法中的各種最短路徑演算法，從不同的角度揭示它們的內核以及它們的異同**
㈢ python幾種遍歷復雜網站的方法原理是什麼
python網路爬蟲原理
互聯網網頁可以看成是一張超大圖,每個網頁是一個節點,網頁中指向其他網頁的鏈接是邊。那麼,可以這樣實現全網網頁收集:以某一個網頁為起點,下載並處理該網頁,解析裡面的鏈接,所得的URL加入下載隊列。這個過程其實就是圖的遍歷過程,可以是深度優先或者廣度優先遍歷,取決於下載隊列如何維護。簡單地,網路爬蟲可以由以下部分組成: 1、下載模塊
㈣ Python怎麼實現廣度優先遍歷
1、從圖中某個頂點V0出發，並訪問此頂點；2、從V0出發，訪問V0的各個未曾訪問的鄰接點W1，W2，…,Wk;然後,依次從W1,W2,…,Wk出發訪問各自未被訪問的鄰接點；3、重復步驟2，直到全部頂點都被訪問為止。
㈤ 圖遍歷演算法之DFS/BFS
在計算機科學， 圖遍歷（Tree Traversal，也稱圖搜索）是一系列圖搜索的演算法， 是單次訪問樹結構類型數據（tree data structure)中每個節點以便檢查或更新的一系列機制。圖遍歷演算法可以按照節點訪問順序進行分類，根據訪問目的或使用場景的不同，演算法大致可分為28種：
圖遍歷即以特定方式訪問圖中所有節點，給定節點下有多種可能的搜索路徑。假定以順序方式進行（非並行），還未訪問的節點就需通過堆棧（LIFO）或隊列（FIFO）規則來確定訪問先後。由於樹結構是一種遞歸的數據結構，在清晰的定義下，未訪問節點可存儲在調用堆棧中。本文介紹了圖遍歷領域最流行的廣度優先搜索演算法BFS和深度優先搜索演算法DFS，對其原理、應用及實現進行了闡述。通常意義上而言，深度優先搜索（DFS）通過遞歸調用堆棧比較容易實現，廣義優先搜索通過隊列實現。
深度優先搜索（DFS）是用於遍歷或搜索圖數據結構的演算法，該演算法從根節點開始（圖搜索時可選擇任意節點作為根節點）沿著每個分支進行搜索，分支搜索結束後在進行回溯。在進入下一節點之前，樹的搜索盡可能的加深。
DFS的搜索演算法如下（以二叉樹為例）：假定根節點（圖的任意節點可作為根節點）標記為 ,
(L) : 遞歸遍歷左子樹，並在節點 結束。
(R): 遞歸遍歷右子樹，並在節點 結束。
(N): 訪問節點 。
這些步驟可以以任意次序排列。如果（L）在（R）之前，則該過程稱為從左到右的遍歷；反之，則稱為從右到左的遍歷。根據訪問次序的不同，深度優先搜索可分為 pre-order、in-order、out-order以及post-order遍歷方式。
（a）檢查當前節點是否為空；
（b）展示根節點或當前節點數據；
（c）遞歸調用pre-order函數遍歷左子樹；
（d）遞歸調用pre-order函數遍歷右子樹。
pre-order遍歷屬於拓撲排序後的遍歷，父節點總是在任何子節點之前被訪問。該遍歷方式的圖示如下：
遍歷次序依次為：F -B -A-D- C-E-G- I-H.
（a）檢查當前節點是否為空；
（b）遞歸調用in-order函數遍歷左子樹；
（c）展示根節點或當前節點數據；
（d）遞歸調用in-order函數遍歷右子樹。
在二叉樹搜索中，in-order遍歷以排序順序訪問節點數據。該遍歷方式的圖示如下：
遍歷次序依次為：A -B - C - D - E - F - G -H-I
（a）檢查當前節點是否為空；
（b）遞歸調用out-order函數遍歷右子樹；
（c）展示根節點或當前節點數據；
（d）遞歸調用out-order函數遍歷左子樹。
該遍歷方式與LNR類似，但先遍歷右子樹後遍歷左子樹。仍然以圖2為例，遍歷次序依次為：H- I-G- F- B- E- D- C- A.
（a）檢查當前節點是否為空；
（b）遞歸調用post-order函數遍歷左子樹；
（c）遞歸調用post-order函數遍歷右子樹；
（d）展示根節點或當前節點數據。
post-order遍歷圖示如下：
遍歷次序依次為：A-C-E-D-B-H-I-G-F.
pre-order遍歷方式使用場景：用於創建樹或圖的副本；
in-order遍歷使用場景：二叉樹遍歷；
post-order遍歷使用場景：刪除樹
遍歷追蹤也稱樹的序列化，是所訪問根節點列表。無論是pre-order，in-order或是post-order都無法完整的描述樹特性。給定含有不同元素的樹結構，pre-order或post-order與in-order遍歷方式結合起來使用才可以描述樹的獨特性。
樹或圖形的訪問也可以按照節點所處的級別進行遍歷。在每次訪問下一層級節點之前，遍歷所在高層級的所有節點。BFS從根節點（圖的任意節點可作為根節點）出發，在移動到下一節點之前訪問所有相同深度水平的相鄰節點。
BFS的遍歷方法圖示如下：
遍歷次序依次為： F-B-G-A-D-I-C-E-H.
圖演算法相關的R包為igraph，主要包括圖的生成、圖計算等一系列演算法的實現。
使用方法：
參數說明：
示例：
結果展示：
DFS R輸出節點排序：
使用方法：
參數含義同dfs
示例：
結果展示：
BFS R輸出節點排序：
以尋找兩點之間的路徑為例，分別展示BFS及DFS的實現。圖示例如下：
示例：
輸出結果：
示例：
輸出結果：
[1] 維基網路： https://en.wikipedia.org/wiki/Tree_traversal
[2] GeeksforGeeks: https://www.geeksforgeeks.org/tree-traversals-inorder-preorder-and-postorder/
[3] http://webdocs.cs.ualberta.ca/~holte/T26/tree-traversal.html
[4]Martin Broadhurst, Graph Algorithm: http://www.martinbroadhurst.com/Graph-algorithms.html#section_1_1
[5]igraph: https://igraph.org/r/doc/dfs.html
[6]igraph: https://igraph.org/r/doc/bfs.html
[7] Depth-First Search and Breadth-First Search in Python: https://eddmann.com/posts/depth-first-search-and-breadth-first-search-in-python/
㈥ python 如何將一段字元串用二叉樹的後序遍歷列印出來
# -*- coding:utf-8 -*-def fromFMtoL( mid ): global las #全局後序遍歷 global fir #先序遍歷 root = fir[0] #取出當前樹根 fir = fir[1:] #取出樹根後 先序遍歷把根拿出來 下面一個元素做樹根 root_po = mid.find( root ) #在中序遍歷當中樹根的位置 left = mid[0:root_po] #左子樹 right = mid[root_po+1:len(mid)] #右子樹 ''' 後序遍歷： 左 右 根 先左子樹 再右子樹 最後跟 ''' #有左子樹的時候 if len(left) > 0: fromFMtoL( left ) #有右子樹的時候 if len(right) > 0: fromFMtoL( right ) #樹根寫進結果 las += rootif __name__ == "__main__" : # fir = input("請輸入先序遍歷：") #前序遍歷的結果 # mid = input("請輸入中序遍歷：") #中序遍歷的結果 fir = "DBACEGF" mid = "ABCDEFG" # fir = "ABC" # mid = "BAC" las = "" fromFMtoL( mid ) print(las)
㈦ 如何用 Python 實現一個圖資料庫（Graph Database）
本文章是 重寫 500 Lines or Less 系列的其中一篇，目標是重寫 500 Lines or Less 系列的原有項目：Dagoba: an in-memory graph database。
Dagoba 是作者設計用來展示如何從零開始自己實現一個圖資料庫（ Graph Database ）。該名字似乎來源於作者喜歡的一個樂隊，另一個原因是它的前綴 DAG 也正好是有向無環圖 （ Directed Acyclic Graph ） 的縮寫。本文也沿用了該名稱。
圖是一種常見的數據結構，它將信息描述為若干獨立的節點（ vertex ，為了和下文的邊更加對稱，本文中稱為 node ），以及把節點關聯起來的邊（ edge ）。我們熟悉的鏈表以及多種樹結構可以看作是符合特定規則的圖。圖在路徑選擇、推薦演算法以及神經網路等方面都是重要的核心數據結構。
既然圖的用途如此廣泛，一個重要的問題就是如何存儲它。如果在傳統的關系資料庫中存儲圖，很自然的做法就是為節點和邊各自創建一張表，並用外鍵把它們關聯起來。這樣的話，要查找某人所有的子女，就可以寫下類似下面的查詢：
還好，不算太復雜。但是如果要查找孫輩呢？那恐怕就要使用子查詢或者 CTE(Common Table Expression) 等特殊構造了。再往下想，曾孫輩又該怎麼查詢？孫媳婦呢？
這樣我們會意識到，SQL 作為查詢語言，它只是對二維數據表這種結構而設計的，用它去查詢圖的話非常笨拙，很快會變得極其復雜，也難以擴展。針對圖而言，我們希望有一種更為自然和直觀的查詢語法，類似這樣：
為了高效地存儲和查詢圖這種數據結構，圖資料庫（ Graph Database ）應運而生。因為和傳統的關系型資料庫存在極大的差異，所以它屬於新型資料庫也就是 NoSql 的一個分支（其他分支包括文檔資料庫、列資料庫等）。圖資料庫的主要代表包括 Neo4J 等。本文介紹的 Dagoba 則是具備圖資料庫核心功能、主要用於教學和演示的一個簡單的圖資料庫。
原文代碼是使用 JavaScript 編寫的，在定義調用介面時大量使用了原型（ prototype ）這種特有的語言構造。對於其他主流語言的用戶來說，原型的用法多少顯得有些別扭和不自然。
考慮到本系列其他資料庫示例大多是用 Python 實現的，本文也按照傳統，用 Python 重寫了原文的代碼。同樣延續之前的慣例，為了讓讀者更好地理解程序是如何逐步完善的，我們用迭代式的方法完成程序的各個組成部分。
原文在 500lines 系列的 Github 倉庫中只包含了實現代碼，並未包含測試。按照代碼注釋說明，測試程序位於作者的另一個代碼庫中，不過和 500lines 版本的實現似乎略有不同。
本文實現的代碼參考了原作者的測試內容，但跳過了北歐神話這個例子——我承認確實不熟悉這些神祇之間的親緣關系，相信中文背景的讀者們多數也未必了解，雖然作者很喜歡這個例子，想了想還是不要徒增困惑吧。因此本文在編寫測試用例時只參考了原文關於家族親屬的例子，放棄了神話相關的部分，盡管會減少一些趣味性，相信對於入門級的代碼來說這樣也夠用了。
本文實現程序位於代碼庫的 dagoba 目錄下。按照本系列程序的同意規則，要想直接執行各個已完成的步驟，讀者可以在根目錄下的 main.py 找到相應的代碼位置，取消注釋並運行即可。
本程序的所有步驟只需要 Python3 ，測試則使用內置的 unittest , 不需要額外的第三方庫。原則上 Python3.6 以上版本應該都可運行，但我只在 Python3.8.3 環境下完整測試過。
本文實現的程序從最簡單的案例開始，通過每個步驟逐步擴展，最終形成一個完整的程序。這些步驟包括：
接下來依次介紹各個步驟。
回想一下，圖資料庫就是一些點（ node ）和邊（ edge ）的集合。現在我們要做出的一個重大決策是如何對節點/邊進行建模。對於邊來說，必須指定它的關聯關系，也就是從哪個節點指向哪個節點。大多數情況下邊是有方向的——父子關系不指明方向可是要亂套的！
考慮到擴展性及通用性問題，我們可以把數據保存為字典（ dict ），這樣可以方便地添加用戶需要的任何數據。某些數據是為資料庫內部管理而保留的，為了明確區分，可以這樣約定：以下劃線開頭的特殊欄位由資料庫內部維護，類似於私有成員，用戶不應該自己去修改它們。這也是 Python 社區普遍遵循的約定。
此外，節點和邊存在互相引用的關系。目前我們知道邊會引用到兩端的節點，後面還會看到，為了提高效率，節點也會引用到邊。如果僅僅在內存中維護它們的關系，那麼使用指針訪問是很直觀的，但資料庫必須考慮到序列化到磁碟的問題，這時指針就不再好用了。
為此，最好按照資料庫的一般要求，為每個節點維護一個主鍵（ _id ），用主鍵來描述它們之間的關聯關系。
我們第一步要把資料庫的模型建立起來。為了測試目的，我們使用一個最簡單的資料庫模型，它只包含兩個節點和一條邊，如下所示：
按照 TDD 的原則，首先編寫測試：
與原文一樣，我們把資料庫管理介面命名為 Dagoba 。目前，能夠想到的最簡單的測試是確認節點和邊是否已經添加到資料庫中：
assert_item 是一個輔助方法，用於檢查字典是否包含預期的欄位。相信大家都能想到該如何實現，這里就不再列出了，讀者可參考 Github 上的完整源碼。
現在，測試是失敗的。用最簡單的辦法實現資料庫：
需要注意的是，不管添加節點還是查詢，程序都使用了拷貝後的數據副本，而不是直接使用原始數據。為什麼要這樣做？因為字典是可變的，用戶可以在任何時候修改其中的內容，如果資料庫不知道數據已經變化，就很容易發生難以追蹤的一致性問題，最糟糕的情況下會使得數據內容徹底混亂。
拷貝數據可以避免上述問題，代價則是需要佔用更多內存和處理時間。對於資料庫來說，通常查詢次數要遠遠多於修改，所以這個代價是可以接受的。
現在測試應該正常通過了。為了讓它更加完善，我們可以再測試一些邊緣情況，看看資料庫能否正確處理異常數據，比如：
例如，如果用戶嘗試添加重復主鍵，我們預期應拋出 ValueError 異常。因此編寫測試如下：
為了滿足以上測試，代碼需要稍作修改。特別是按照 id 查找主鍵是個常用操作，通過遍歷的方法效率太低了，最好是能夠通過主鍵直接訪問。因此在資料庫中再增加一個字典：
完整代碼請參考 Github 倉庫。
在上個步驟，我們在初始化資料庫時為節點明確指定了主鍵。按照資料庫設計的一般原則，主鍵最好是不具有業務含義的代理主鍵（ Surrogate key ），用戶不應該關心它具體的值是什麼，因此讓資料庫去管理主鍵通常是更為合理的。當然，在部分場景下——比如導入外部數據——明確指定主鍵仍然是有用的。
為了同時支持這些要求，我們這樣約定：欄位 _id 表示節點的主鍵，如果用戶指定了該欄位，則使用用戶設置的值（當然，用戶有責任保證它們不會重復）；否則，由資料庫自動為它分配一個主鍵。
如果主鍵是資料庫生成的，事先無法預知它的值是什麼，而邊（ edge ）必須指定它所指向的節點，因此必須在主鍵生成後才能添加。由於這個原因，在動態生成主鍵的情況下，資料庫的初始化會略微復雜一些。還是先寫一個測試：
為支持此功能，我們在資料庫中添加一個內部欄位 _next_id 用於生成主鍵，並讓 add_node 方法返回新生成的主鍵：
接下來，再確認一下邊是否可以正常訪問：
運行測試，一切正常。這個步驟很輕松地完成了，不過兩個測試（ DbModelTest 和 PrimaryKeyTest ）出現了一些重復代碼，比如 get_item 。我們可以把這些公用代碼提取出來。由於 get_item 內部調用了 TestCase.assertXXX 等方法，看起來應該使用繼承，但從 TestCase 派生基類容易引起一些潛在的問題，所以我轉而使用另一個技巧 Mixin ：
實現資料庫模型之後，接下來就要考慮如何查詢它了。
在設計查詢時要考慮幾個問題。對於圖的訪問來說，幾乎總是由某個節點（或符合條件的某一類節點）開始，從與它相鄰的邊跳轉到其他節點，依次類推。所以鏈式調用對查詢來說是一種很自然的風格。舉例來說，要知道 Tom 的孫子養了幾只貓，可以使用類似這樣的查詢：
可以想像，以上每個方法都應該返回符合條件的節點集合。這種實現是很直觀的，不過存在一個潛在的問題：很多時候用戶只需要一小部分結果，如果它總是不計代價地給我們一個巨大的集合，會造成極大的浪費。比如以下查詢：
為了避免不必要的浪費，我們需要另外一種機制，也就是通常所稱的「懶式查詢」或「延遲查詢」。它的基本思想是，當我們調用查詢方法時，它只是把查詢條件記錄下來，而並不立即返回結果，直到明確調用某些方法時才真正去查詢資料庫。
如果讀者比較熟悉流行的 Python ORM，比如 SqlAlchemy 或者 Django ORM 的話，會知道它們幾乎都是懶式查詢的，要調用 list(result) 或者 result[0:10] 這樣的方法才能得到具體的查詢結果。
在 Dagoba 中把觸發查詢的方法定義為 run 。也就是說，以下查詢執行到 run 時才真正去查找數據：
和懶式查詢（ Lazy Query ）相對應的，直接返回結果的方法一般稱作主動查詢（ Eager Query ）。主動查詢和懶式查詢的內在查找邏輯基本上是相同的，區別只在於觸發機制不同。由於主動查詢實現起來更加簡單，出錯也更容易排查，因此我們先從主動查詢開始實現。
還是從測試開始。前面測試所用的簡單資料庫數據太少，難以滿足查詢要求，所以這一步先來創建一個更復雜的數據模型：
此關系的復雜之處之一在於反向關聯：如果 A 是 B 的哥哥，那麼 B 就是 A 的弟弟/妹妹，為了查詢到他們彼此之間的關系，正向關聯和反向關聯都需要存在，因此在初始化資料庫時需要定義的邊數量會很多。
當然，父子之間也存在反向關聯的問題，為了讓問題稍微簡化一些，我們目前只需要向下（子孫輩）查找，可以稍微減少一些關聯數量。
因此，我們定義數據模型如下。為了減少重復工作，我們通過 _backward 欄位定義反向關聯，而資料庫內部為了查詢方便，需要把它維護成兩條邊：
然後，測試一個最簡單的查詢，比如查找某人的所有孫輩：
這里 outcome/income 分別表示從某個節點出發、或到達它的節點集合。在原作者的代碼中把上述方法稱為 out/in 。當然這樣看起來更加簡潔，可惜的是 in 在 Python 中是個關鍵字，無法作為函數名。我也考慮過加個下劃線比如 out_.in_ 這種形式，但看起來也有點怪異，權衡之後還是使用了稍微啰嗦一點的名稱。
現在我們可以開始定義查詢介面了。在前面已經說過，我們計劃分別實現兩種查詢，包括主動查詢（ Eager Query ）以及延遲查詢（ Lazy Query ）。
它們的內在查詢邏輯是相通的，看起來似乎可以使用繼承。不過遵循 YAGNI 原則，目前先不這樣做，而是只定義兩個新類，在滿足測試的基礎上不斷擴展。以後我們會看到，與繼承相比，把共同的邏輯放到資料庫本身其實是更為合理的。
接下來實現訪問節點的方法。由於 EagerQuery 調用查詢方法會立即返回結果，我們把結果記錄在 _result 內部欄位中。雖然 node 方法只返回單個結果，但考慮到其他查詢方法幾乎都是返回集合，為統一起見，讓它也返回集合，這樣可以避免同時支持集合與單結果的分支處理，讓代碼更加簡潔、不容易出錯。此外，如果查詢對象不存在的話，我們只返回空集合，並不視為一個錯誤。
查詢輸入/輸出節點的方法實現類似這樣：
查找節點的核心邏輯在資料庫本身定義：
以上使用了內部定義的一些輔助查詢方法。用類似的邏輯再定義 income ，它們的實現都很簡單，讀者可以直接參考源碼，此處不再贅述。
在此步驟的最後，我們再實現一個優化。當多次調用查詢方法後，結果可能會返回重復的數據，很多時候這是不必要的。就像關系資料庫通常支持 unique/distinct 一樣，我們也希望 Dagoba 能夠過濾重復的數據。
假設我們要查詢某人所有孩子的祖父，顯然不管有多少孩子，他們的祖父應該是同一個人。因此編寫測試如下：
現在來實現 unique 。我們只要按照主鍵把重復數據去掉即可：
在上個步驟，初始化資料庫指定了雙向關聯，但並未測試它們。因為我們還沒有編寫代碼去支持它們，現在增加一個測試，它應該是失敗的：
運行測試，的確失敗了。我們看看要如何支持它。回想一下，當從邊查找節點時，使用的是以下方法：
這里也有一個潛在的問題：調用 self.edges 意味著遍歷所有邊，當資料庫內容較多時，這是巨大的浪費。為了提高性能，我們可以把與節點相關的邊記錄在節點本身，這樣要查找邊只要看節點本身即可。在初始化時定義出入邊的集合：
在添加邊時，我們要同時把它們對應的關系同時更新到節點，此外還要維護反向關聯。這涉及對字典內容的部分復制，先編寫一個輔助方法：
然後，將添加邊的實現修改如下：
這里的代碼同時添加正向關聯和反向關聯。有的朋友可能會注意到代碼略有重復，是的，但是重復僅出現在該函數內部，本著「三則重構」的原則，暫時不去提取代碼。
實現之後，前面的測試就可以正常通過了。
在這個步驟中，我們來實現延遲查詢（ Lazy Query ）。
延遲查詢的要求是，當調用查詢方法時並不立即執行，而是推遲到調用特定方法，比如 run 時才執行整個查詢，返回結果。
延遲查詢的實現要比主動查詢復雜一些。為了實現延遲查詢，查詢方法的實現不能直接返回結果，而是記錄要執行的動作以及傳入的參數，到調用 run 時再依次執行前面記錄下來的內容。
如果你去看作者的實現，會發現他是用一個數據結構記錄執行操作和參數，此外還有一部分邏輯用來分派對每種結構要執行的動作。這樣當然是可行的，但數據處理和分派部分的實現會比較復雜，也容易出錯。
本文的實現則選擇了另外一種不同的方法：使用 Python 的內部函數機制，把一連串查詢變換成一組函數，每個函數取上個函數的執行結果作為輸入，最後一個函數的輸出就是整個查詢的結果。由於內部函數同時也是閉包，盡管每個查詢的參數形式各不相同，但是它們都可以被閉包「捕獲」而成為內部變數，所以這些內部函數可以採用統一的形式，無需再針對每種查詢設計額外的數據結構，因而執行過程得到了很大程度的簡化。
首先還是來編寫測試。 LazyQueryTest 和 EagerQueryTest 測試用例幾乎是完全相同的（是的，兩種查詢只在於內部實現機制不同，它們的調用介面幾乎是完全一致的）。
因此我們可以把 EagerQueryTest 的測試原樣不變拷貝到 LazyQueryTest 中。當然拷貝粘貼不是個好注意，對於比較冗長而固定的初始化部分，我們可以把它提取出來作為兩個測試共享的公共函數。讀者可參考代碼中的 step04_lazy_query/tests/test_lazy_query.py 部分。
程序把查詢函數的串列執行稱為管道（ pipeline ），用一個變數來記錄它：
然後依次實現各個調用介面。每種介面的實現都是類似的：用內部函數執行真正的查詢邏輯，再把這個函數添加到 pipeline 調用鏈中。比如 node 的實現類似下面：
其他介面的實現也與此類似。最後， run 函數負責執行所有查詢，返回最終結果；
完成上述實現後執行測試，確保我們的實現是正確的。
在前面我們說過，延遲查詢與主動查詢相比，最大的優勢是對於許多查詢可以按需要訪問，不需要每個步驟都返回完整結果，從而提高性能，節約查詢時間。比如說，對於下面的查詢：
以上查詢的意思是從孫輩中找到一個符合條件的節點即可。對該查詢而言，主動查詢會在調用 outcome('son') 時就遍歷所有節點，哪怕最後一步只需要第一個結果。而延遲查詢為了提高效率，應在找到符合條件的結果後立即停止。
目前我們尚未實現 take 方法。老規矩，先添加測試：
主動查詢的 take 實現比較簡單，我們只要從結果中返回前 n 條記錄：
延遲查詢的實現要復雜一些。為了避免不必要的查找，返回結果不應該是完整的列表（ list ），而應該是個按需返回的可迭代對象，我們用內置函數 next 來依次返回前 n 個結果：
寫完後運行測試，確保它們是正確的。
從外部介面看，主動查詢和延遲查詢幾乎是完全相同的，所以用單純的數據測試很難確認後者的效率一定比前者高，用訪問時間來測試也並不可靠。為了測試效率，我們引入一個節點訪問次數的概念，如果延遲查詢效率更高的話，那麼它應該比主動查詢訪問節點的次數更少。
為此，編寫如下測試：
我們為 Dagoba 類添加一個成員來記錄總的節點訪問次數，以及兩個輔助方法，分別用於獲取和重置訪問次數：
然後瀏覽代碼，查找修改點。增加計數主要在從邊查找節點的時候，因此修改部分如下：
此外還有 income/outcome 方法，修改都很簡單，這里就不再列出。
實現後再次運行測試。測試通過，表明延遲查詢確實在效率上優於主動查詢。
不像關系資料庫的結構那樣固定，圖的形式可以千變萬化，查詢機制也必須足夠靈活。從原理上講，所有查詢無非是從某個節點出發按照特定方向搜索，因此用 node/income/outcome 這三個方法幾乎可以組合出任意所需的查詢。
但對於復雜查詢，寫出的代碼有時會顯得較為瑣碎和冗長，對於特定領域來說，往往存在更為簡潔的名稱，例如：母親的兄弟可簡稱為舅舅。對於這些場景，如果能夠類似 DSL （領域特定語言）那樣允許用戶根據專業要求自行擴展，從而簡化查詢，方便閱讀，無疑會更為友好。
如果讀者去看原作者的實現，會發現他是用一種特殊語法 addAlias 來定義自己想要的查詢，調用方法時再進行查詢以確定要執行的內容，其介面和內部實現都是相當復雜的。
而我希望有更簡單的方法來實現這一點。所幸 Python 是一種高度動態的語言，允許在運行時向類中增加新的成員，因此做到這一點可能比預想的還要簡單。
為了驗證這一點，編寫測試如下：
無需 Dagoba 的實現做任何改動，測試就可以通過了！其實我們要做的就是動態添加一個自定義的成員函數，按照 Python 對象機制的要求，成員函數的第一個成員應該是名為 self 的參數，但這里已經是在 UnitTest 的內部，為了和測試類本身的 self 相區分，新函數的參數增加了一個下劃線。
此外，函數應返回其所屬的對象，這是為了鏈式調用所要求的。我們看到，動態語言的靈活性使得添加新語法變得非常簡單。
到此，一個初具規模的圖資料庫就形成了。
和原文相比，本文還缺少一些內容，比如如何將資料庫序列化到磁碟。不過相信讀者都看到了，我們的資料庫內部結構基本上是簡單的原生數據結構（列表+字典），因此序列化無論用 pickle 或是 JSON 之類方法都應該是相當簡單的。有興趣的讀者可以自行完成它們。
我們的圖資料庫實現為了提高查詢性能，在節點內部存儲了邊的指針（或者說引用）。這樣做的好處是，無論資料庫有多大，從一個節點到相鄰節點的訪問是常數時間，因此數據訪問的效率非常高。
但一個潛在的問題是，如果資料庫規模非常大，已經無法整個放在內存中，或者出於安全性等原因要實現分布式訪問的話，那麼指針就無法使用了，必須要考慮其他機制來解決這個問題。分布式資料庫無論採用何種數據模型都是一個棘手的問題，在本文中我們沒有涉及。有興趣的讀者也可以考慮 500lines 系列中關於分布式和集群演算法的其他一些文章。
本文的實現和系列中其他資料庫類似，採用 Python 作為實現語言，而原作者使用的是 JavaScript ，這應該和作者的背景有關。我相信對於大多數開發者來說， Python 的對象機制比 JavaScript 基於原型的語法應該是更容易閱讀和理解的。
當然，原作者的版本比本文版本在實現上其實是更為完善的，靈活性也更好。如果想要更為優雅的實現，我們可以考慮使用 Python 元編程，那樣會更接近於作者的實現，但也會讓程序的復雜性大為增加。如果讀者有興趣，不妨對照著去讀讀原作者的版本。
㈧ 如何用python解析graphml格式的xml文件並廣度優先遍歷
這個任務的關鍵點有三處：
一個是解析xml，獲取node與edge的信息，python自帶的xml.etree.ElementTree就可以；
二是構造圖的數據結構，可以用鄰接鏈表；
三是做BFS，這個是標準的圖演算法，在二的基礎上不難實現。
建議題主先試著自己做一做。加油。