首先初步了解 DParser 這一由 J. Plevyak 編寫的簡單而強大的解析工具。然後了解用於 Python 的 DParser，它為 Python 程序員 提供了一個訪問 DParser 的無縫接口，並看看它與上一期中介紹的解析器的比較。語法規則以類似於 Spark 或 PLY 的方式通過 Python
首先初步了解 DParser 這一由 J. Plevyak 編寫的簡單而強大的解析工具。然後了解用於 Python 的 DParser，它為 Python
程序員提供了一個訪問 DParser 的無縫接口，並看看它與上一期中介紹的解析器的比較。語法規則以類似於 Spark 或 PLY 的方式通過 Python 函數文檔字符串加入到 DParser 中。
有很多可用的 Python 解析器程序庫。我已經在本專欄中討論過 mx.TextTools、SimpleParse 和 SPARK，並在我的書中介紹了 PLY（請參閱 參考資料，獲得這些文檔的鏈接）。無需考慮，我也知道有 PyGgy、Yapps、PLEX、Py
LR、PyParsing 和 TPG，而且我還模糊地記得讀過半打其他解析器的聲明。用戶可能會對此門類感到失落，不是因為缺少高
質量程序庫，而是太多了。
DParser 與所有其他解析器的不同之處是什麼？是這樣，類似於 PLY 和 Spark，用於 Python 的 DParser 使用函數文檔字符串來表示其結果（productions）。這種風格使得您可以將動作代碼直接插入到一個結果中，以處理當一個特定的語法規則得到滿足時將發生的事件。與 PLY 或 Spark 相反，DParser 本身是用 C 編寫的，因而可能會比純粹的 Python 解析器快得多。用於 Python 的 DParser 是底層的 C 程序庫之外的一個非常精簡的包裝器（wrapper） —— 對 Python 的回調需要一些額外的時間，但是基本的解析是以 C 語言的速度來進行的。不過，就本文而言，我沒有嘗試進行任何具體的基准
測試。所以，相對於其他解析器來說，DParser 到底有多快或多慢不是我所能直接評論的。
就我自己而言，我仍是非常喜歡 SimpleParse 的方法。SimpleParse 是快速的 mx.TextTools 程序庫（也是用 C 所編寫的）的一個包裝器，可以將 EBNF 語法語言從 Python 代碼中完全分離出來。一般來說，使用 SimpleParse 就意味著在一個函數調用中生成一個解析樹，然後在分開的代碼中遍歷這個樹。對於特別大的被解析的文檔來說，這種兩步方法可能是低效的，但是我發現這樣更容易理解編寫的代碼。
盡管如此，還是有很多讀者推薦說用於 Python DParaser 值得關注，雖然我更喜歡單獨的 EBNF 定義。順便提一句，如您將在示例中所看到的，DParser 不使用任何單獨的標記傳遞，而只是直接解析。您可以通過定義保留的 d_whitespace() 函數來控制空格的識別（它分離解析符號）；這樣就使得您可以隨意使用標記。
找到最長的結果 作為用於 Python 的 DParser 程序的第一個示例，我創建了一個查找幾個模式的語法，這些模式依次為另一個的子結果。這個語法處理的問題類似於很多解析器遇到的“dangling else”問題。具體說，也就是您如何才能知道什麼時候停止查找更長的結果？（例如，“if”後是否跟有“else”？）我的語法會去分析的短語可能按次序包括有以“a”、“b”和“c” 結尾的單詞。所有沒有被包括進來的單詞只是短語的“head”或“tail”的部分。這需要一些例子來展示。首先，程序本身：
清單 1. 解析器 abc.py
#!/usr/bin/env python2.3
"Identify sequence of a-, b-, c- words"
#
#-- The grammar
def d_phrase(t, s):
'phrase : words ( ABC | AB | A ) words'
print "Head:", '.join(s[0])
print t[1][0]+":", '.join(s[1])
print "Tail:", '.join(s[2])
def d_words(t):
'words : word*'
def d_word(t):
'word : "[a-z]+" '
def d_A(t):
''A : "a[a-z]*" ''
return 'A'
def d_AB(t):
''AB : A "b[a-z]*" ''
return 'AB'
def d_ABC(t):
''ABC : AB "c[a-z]*" ''
return 'ABC'
#
#-- Parse S
TDIN
from dparser import Parser
from sys import argv, s
tdin
phrase, arg = stdin.read(), argv[-1]
Parser().parse(phrase,
print_de
bug_info=(arg=='--debug'))
讓我們給出一些短語來運行這個解析器，如下：
清單 2. 簡單地解析短語
$ echo -n "alpha" | ./abc.py
Head:
A: alpha
Tail:
echo -n "xavier alpha beta charlie will" | ./abc.py
Head: xavier
ABC: alpha beta charlie
Tail: will
$ echo -n "mable delta xavier bruce" | ./abc.py
Traceback (most recent call last): [...]
dparser.SyntaxError:
syntax error, line:1
mable delta xavier bruce[syntax error]
顯然，到目前為止，一切都沒問題。我的語法當其條件允許時找到了一個 ABC，但是當只能找到 A 或者 AB 時，也能滿足於此。
不過說實話，當遇到含糊的短語時，我的語法會有很多問題。在大部分情況下，當 DParser 不能確定如何解析一個短語時，它會陷入一個無限循環（可能是最壞的結果；至少回溯或者報告的錯誤可以告訴您哪裡出現了問題）。有時（至少在我的 Mac OSX 機器上），它會轉而生成一個“Bus error”。那些情形我哪個都不喜歡。
處理含糊的短語 由於所有的最終結果都有相同的優先級，所以解析器不能確定如何解析類似如下的內容：
清單 3. 嘗試解析一個含糊的短語
$ echo -n "alex bruce alice benny carl" | ./abc.py
AB 在前然後是單詞？單詞在前然後是 ABC？對於那個問題來說，它是全部都是單詞嗎（包括五個單詞結果），它是不是應該引發一個 dparser.SyntaxError？我最後會得到一個“Bus error” 或停止了的任務，而不是一個解析。在先前的例子中，含糊的短語碰巧被解析出來的原因在於每個結果的急切性（eagerness）；一旦找到一個 ABC，則先導和結尾單詞就都各就其位。
實際上，在先前的語法可以生效的情況下，要確切地理解為什麼能夠生效很令人迷惑 —— 在某種程度上，比理解為什麼它有時不能生效更令人迷惑。
讓我們假定我們希望解析一個短語，並當存在 ABC 結果時找它，即便在從左到右的遍歷過程中，有一些其他的結果（也就是 AB）得到了滿足。我可以通過提高 ABC 最終結果的優先級來完成：
清單 4. abc2.py 中修訂的 d_ABC() 結果函數
def d_ABC(t):
'ABC : AB "c[a-z]*" $term 1'
return 'ABC'
如果沒有指定優先級，則結果的優先級是 0。否則，任何正整數或負整數都可以用來對結果排序。現在我們可以運行：
清單 5. 成功地找到後面的 ABC
$ echo -n "alex bruce alice benny carl" | ./abc2.py
Head: alex bruce
ABC: alice benny carl
Tail:
注意，在解析器尋找末尾的單詞之前，會嘗試（ABC|AB|A）系列中的全部可選項。所以這樣不需要任何優先級規范就可以成功。
清單 6. A 與 AB 之間不存在含糊短語問題
$ echo -n "alex alice benny" | ./abc.py Head: alex
AB: alice benny
Tail:
在處理含糊短語時 DParser 的行為中，我發現了一些難以解釋的異常現象。例如，添加一個絕對不是 A 的末尾單詞，解析器可以工作 —— 但 只能 在有調試信息的條件下運行!
清單 7. 處理含糊短語時的不穩定行為
$ echo -n "alex bruce alice benny carl dave" | ./abc.py
[...process freezes...]
$ echo -n "alex bruce alice benny carl dave" | ./abc.py --debug
[...debugging trace of speculative and final productions...]
Head: alex bruce
ABC: alice benny carl
Tail: dave
abc2.py 中的優先級規范會完成任意一種情況下的解析。
含糊短語的解析相當難以捉摸，難以確切理解。基本上，結果的生成是按遍歷的順序從左到右執行的，每一個結果都嘗試去從左到右獲取盡可能多的單詞。只有當向前查找過程中發生明顯錯誤時，才會進行回溯。總之，這只是大概。
調試簡介 DParser 可以顯示調試信息的選項，這是我所喜歡的它的一個方面。觀察這些信息並不是直觀地創建正確語法所必需的，但是至少可以通過它洞察當處理特定的短語時解析器所采取的動作。例如：
清單 8. 展示對不確定結果的追蹤
#------- Showing a trace of speculative productions
$ echo -n "alex alice benny carl dave" | ./abc2.py --debug
d_words ???:
d_A ???: alex
d_word ???: alex
d_words ???:
d_phrase ???: alex
d_words ???: alex
d_A ???: alice
d_word ???: alice
d_words ???:
d_words ???: alice
d_phrase ???: alex alice
d_phrase ???: alex alice
d_words ???: alex alice
d_word ???: benny
d_AB ???: alice benny
d_words ???: benny
d_words ???: alice benny
d_words ???:
d_phrase ???: alex alice benny
d_phrase ???: alex alice benny
d_phrase ???: alex alice benny
d_words ???: alex alice benny
d_word : alex
d_words : alex
d_A : alice
d_AB : alice benny
d_ABC ???: alice benny carl
d_words ???:
d_phrase ???: alex alice benny carl
d_ABC : alice benny carl
d_word ???: dave
d_words ???: dave
d_phrase ???: alex alice benny carl dave
d_word : dave
d_words : dave
d_phrase : alex alice benny carl dave
Head: alex
ABC: alice benny carl
Tail: dave
後面跟有問號的結果是推測性的嘗試；那些後面其實沒有最終的結果。與此相關， DParser 讓您有能力當結果成為推測的或者是最終解析時采取不同的動作。默認情況下，函數體中的動作只作用於最終解析。不過，您可以向結果指定兩個額外參數中的一個來處理推測性解析。（還有很多本文中沒有討論的選項參數。）
清單 9. 推測性解析過程中的動作
def d_prod1(t, spec_only):
'prod1 : this that+ other?'
print "Speculative parse of prod1"
def d_prod2(t, spec):
'prod2: spam* eggs toast'
if spec:
print "Speculative parse of prod2"
else:
print "Final parse of prod2"
當然，通過指定 dparser.Parser.parse() 的 print_debug_info 參數，我的推測性解析所顯示的所有信息也都顯示出來（以稍微不同的格式）。不過您也可以決定采取其他動作 —— 比如觸發外部事件。
深入探討優先級 我承認，前面 ABC 結果所使用的指定優先級有些不太正統。但是假如是簡單含糊短語，則微調結束優先級是一個非常好的工具。讓我來給出另一個關於簡單含糊短語的語法：
清單 10. 逐項的二義性語法，ibm.py
def d_phrase(t, s):
'phrase : word ( vowel | caps | threeletter ) word'
print "Head:", '.join(s[0])
print t[1][0]+":", '.join(s[1])
print "Tail:", '.join(s[2])
def d_word(t): 'word : "[A-Za-z]+" '
def d_vowel(t):
'vowel : "[AEIOUaeiou][A-Za-z]*"'
return 'VOWEL'
def d_caps(t):
'caps : "[A-Z]+"'
return 'CAPS'
def d_threeletter(t):
'threeletter : "[A-Za-z][A-Za-z][A-Za-z]"'
return '3LETT'
#-- Parse STDIN
from dparser import Parser
from sys import stdin
Parser().parse(stdin.read())
vowel、caps 和 threeletter 的結果不需要是確切的；它們全部都可以獲取彼此有重疊的單詞集合。例如：
清單 11. 當 DParser 得體地檢測到含糊短語
$ echo -n "Read IBM developerWorks" | ./ibm.py
Traceback (most recent call last): [...]
dparser.AmbiguityException: [...]
當然，您可能幸運地使用了特定的短語：
清單 12. 幸運地避免了含糊短語的解析
$ echo -n "Read GNOSIS website" | ./ibm.py
Head: Read
CAPS: GNOSIS
Tail: website
不要滿足於祈禱好運，讓我們來顯式地指定結果之間的優先級：
清單 13. 判定含糊的條件，ibm2.py
def d_vowel(t):
'vowel : "[AEIOUaeiou][A-Za-z]*" $term 3'
return 'VOWEL'
def d_caps(t):
'caps : "[A-Z]+" $term 2'
return 'CAPS'
def d_threeletter(t):
'threeletter : "[A-Za-z][A-Za-z][A-Za-z]" $term 1'
return '3LETT'
現在，每一個短語都將以特定的順序識別出中間單詞的類型（當然只是可能的那些）：
清單 14. 無歧義的解析結果
$ echo -n "Read IBM developerWorks" | ./ibm2.py
Head: Read
VOWEL: IBM
Tail: developerWorks
$ echo -n "Read XYZ journal" | ./ibm2.py
Head: Read
CAPS: XYZ
Tail: journal
做出決定 盡管得到了一些讀者的建議，我還是不太看重 DParser。它有很多可以作用於結果的強大的開關和選項，我還沒有討論到 —— 比如指定關聯性。大體上，DParser 語言非常健壯，我非常懷疑用於 Python 的 DParser 是否會比純粹的 Python 解析器運行速度快得非常多。
無論如何，我仍然不能對函數文檔字符串風格的解析器具有太多熱情。顯然，關於這一點，很多優秀的 Python 程序員不會贊同我。此外我還發現一些解析結果有些令人不解：為什麼調試模式下可以成功，而標准模式下卻不能成功？含糊問題確切是什麼時候發生的？使用任何解析工具
開發語法都會有類似的意外，但是我發現 DParser 不知何故尤其出乎意料；例如 SimpleParse，就不會讓我那麼感到驚訝。可能，如果我了解了底層算法的更多復雜細節，它將會更具意義；不過，就我相對淺薄的學識而言，我可能與 95% 以上的讀者差不多。有人比我更加熟悉解析；但是實際上大部分程序員懂得更少。
