文章轉自：https://zhuanlan.zhihu.com/p/154356033侵刪
字典合並
一個非常優雅的特性，當我們想將兩個字典進行合並時，只需要使用操作符“|”：
a = {1: 'a', 2: 'b', 3: 'c'}
b = {4: 'd', 5: 'e'}
c = a | b
print(c)
輸出結果：
[Out]: {1: 'a', 2: 'b', 3: 'c', 4: 'd', 5: 'e'}
不僅如此，我們還可以使用合並更新操作符“|=”直接對原始字典進行更新：
a = {1: 'a', 2: 'b', 3: 'c'}
b = {4: 'd', 5: 'e'}
a |= b
print(a)
輸出結果：
[Out]: {1: 'a', 2: 'b', 3: 'c', 4: 'd', 5: 'e'}
這里需要注意的是，如果兩個字典都包含相同的Key，運算結果將直接采用第二個字典的鍵值對：
a = {1: 'a', 2: 'b', 3: 'c', 6: 'in both'}
b = {4: 'd', 5: 'e', 6: 'but different'}
print(a | b)
輸出結果：
[Out]: {1: 'a', 2: 'b', 3: 'c', 6: 'but different', 4: 'd', 5: 'e'}
可迭代對象的字典更新
“|=”操作符還具有另一個非常棒的功能，就是使用一個可迭代對象的鍵值對更新字典：
a = {'a': 'one', 'b': 'two'}
b = ((i, i**2) for i in range(3))
a |= b
print(a)
輸出結果：
[Out]: {'a': 'one', 'b': 'two', 0: 0, 1: 1, 2: 4}
這里需要注意的是，如果你使用標准的合並操作符“|”來取代上面的“|=”操作服，這會直接導致TypeError。
TypeError：unsupported opprand type(s) for |：'dict' and 'generator'
類型提示
Python作為動態類型的編程語言，這意味着在使用中我們並不需要給變量指定數據類型。然而雖然可以這樣做，但是這讓我們在維護代碼時常常感到困惑，並且靈活性也成了缺點。
在3.5版本后，雖然我們可以指定數據類型了，但是使用起來仍然非常麻煩。這次新版本就對此進行了更新：沒有類型提示vs有類型提示
上圖中我們想通過add_int函數將兩個相同的數字想加到一起，然而編譯器並沒有很好的理解我們的意圖，由於兩個字符串也可以使用+進行連接，所以這里並沒有給出警告。
現在當我們可以指定函數的參數類型時，在參數類型為int時，編譯器就能夠立即識別上述的問題。
新增字符串函數
雖然字符串函數沒有其他新特性那么強大，但字符串作為開發中使用最頻繁的數據類型，這里也需要提一下他的改變。新版本中添加了移除前綴和后綴的兩個字符串函數：
"Hello world".removeprefix("He")
Hello world".removesuffix("ld")
輸出結果：
[Out]: "llo world"
[Out]: "Hello wor"
新的解析器
為一個普通的開發者，語法解析器的變化可能不易被察覺，但它的變化有可能成為Python演變中的一個重要轉折點。
我們所知，目前Python主要是用的是一種基於LL(1)的語法，這種語法可以通過LL(1)解析器進行解析，該解析器從上到下、從左到右地解析代碼，只需要從詞法分析器中取出一個 token 就可以正確地解析下去。
然而LL(1) 存在的一些問題：
- Python 中包含非 LL(1) 語法，正因如此，當前語法采用了一些曲線救國的辦法，帶來了很多不必要的復雜性。
- LL(1) 給 Python 語法造成了很多限制。某個相關話題提到了下面代碼無法用當前的解析器進行解析（會造成 SyntaxError）。
with (open("a_really_long_foo") as foo,
open("a_really_long_bar") as bar):
pass
- LL(1) 不能處理左遞歸。特定的遞歸語法意味着解析樹時可能出現無限循環。Python 的締造者 Guido van Rossum 在這篇文章[1]中給出了解釋。
毫無疑問，這些因素以及更多無法理解的其他問題影響着Python的發展，而新版本的解析器是基於PEG，它將給 Python 開發者提供更大的靈活性，從 Python 3.10開始我們將能夠感受到這一點。
到這里 Python 3.9的版本幾個重要的特性就講解完畢，我們已經迫不及待的希望正式版的到來。