原作：Jake Edge
譯者：豌豆花下貓@Python貓
英文：https://lwn.net/Articles/819853/
隨著 Python 3.9.0b1 的發布，即開發周期中計劃的四個 beta 版本的首個，Python 3.9 的功能已經是完善了，在 10 月發布最終版本之前，還會有許多測驗和穩定性方面的作業要做，
（譯注：beta1 版本發布于 5 月 18 日，作者文章寫于 5 月 20，而到本篇譯文發布時，beta2 剛好在今天即 6 月 9 日發布，這是一個巧合！）
該發布說明中列出了被 3.9 接受的 7 個 Python 增強提案（PEP），我們研究了其中的一些 PEP，看到有一些更新，現在似乎是一個介紹 Python 3.9 帶來的一些東西的好時機，
1、字串操作
有時最簡單（表明上的）的事情最困難，或者至少會引起巨大的討論，其中大部分的爭議是關于命名（還能是什么？），但是給標準字串物件添加函式，來洗掉前綴和后綴，這種想法是毫無爭議的，
是否可以將那些詞綴（前綴和后綴的統稱）指定為序列，以便在一次呼叫中處理多個詞綴，這一點尚不明確，最后它被從提案中洗掉了，等待著其他人再次推動更改，
在 3 月底，Dennis Sweeney 在 python-dev 郵件串列上請求核心開發者支持 PEP 616（“字串洗掉前綴和后綴的方法”），他指出了自 2019 年 3 月以來關于該話題的 python-ideas 討論，埃里克·史密斯（Eric V. Smith）同意支持該 PEP，這促使 Sweeney 發布并啟動了討論，
在最初版本中，他使用 cutprefix() 和 cutsuffix() 作為要添加給字串物件的方法名，四種型別的 Python 物件將獲得新的方法：str（Unicode 字串），byte（二進制序列），bytearray（可變的二進制序列）和 collections.UserString（字串物件的一種封裝），
它的寫法如下：
'abcdef'.cutprefix('abc') # 回傳'def'
'abcdef'.cutsuffix('ef') # 回傳'abcd'
針對命名部分，出現了一大堆的建議，基本上很少有人喜歡“cut”，因此“strip”、“strim”和“remove”被提出來了，并且都獲得了一些支持，
stripprefix() 以及 stripsuffix() 由于 PEP 中指出的一種理由，至少是被部分地反對了；現有的“strip”函式令人困惑，因此應避免重用該名稱，
str.lstrip() 和 str.rstrip() 方法也用于洗掉前導字符和尾隨字符，但是它們對于真正在尋找 cutprefix() 功能的程式員來說是一個困惑的來源，
*strip() 在呼叫時接收一個字串引數，但會將其視為一組字符，并從字串開頭或結尾消除：
'abcdef'.lstrip('abc') # 回傳“def”，符合預期
'abcbadefed'.lstrip('abc') # 回傳'defed'，完全不符合預期
最終，removeprefix() 和 removesuffix() 似乎占據了上風，這正是 Sweeney 最終改成的版本，Guido van Rossum 也支持這些名字，
埃里克·法格倫（Eric Fahlgren）這樣搞笑地總結了命名的爭論：
我認為如果你先寫檔案，則名稱的選擇會更容易些：
cutprefix - 洗掉指定的前綴，
trimprefix - 洗掉指定的前綴，
stripprefix - 洗掉指定的前綴，
removeprefix - 洗掉指定的前綴，廢話 ??
Sweeney 更新了 PEP，回應了許多評論，但還增加了提議將字串元組作為詞綴的功能（可以在 PEP GitHub 倉庫中看到該版本），
但是史蒂文·達普拉諾（Steven D'Aprano）不確定這樣做是否合理，他指出，唯一接受元組引數的字串操作是 str.startswith() 和 str.endswith()，而它們不回傳字串（只是一個布林值），他懷疑添加這一種接收元組引數卻回傳字串的方法，因為無論選擇何種規則來處理元組，對于某些人來說都是“錯誤的”選擇，
例如：
這里的困難在于，如果兩個或多個前綴都能匹配，則“剪切這些前綴中的一個”的概念是模棱兩可的，對 startwith 沒有區別：
"extraordinary".startswith(('ex', 'extra'))因為是從左到右，從最短到最大，甚至是隨機順序匹配都為True，但是對于 cutprefix，應該洗掉哪個前綴？
如他所說，建議的規則是使用從左到右處理元組的第一個匹配字串，但是有些人可能想要最長的匹配或最后一個匹配；這一切都取決于使用的背景關系，他建議在提交添加此類行為之前，要給該功能更多的“浸泡時間”（譯注：即預備時間）：“在添加多前綴/后綴的支持之前，我們首先應該對簡單的情況進行一些實際的體驗，”
伊桑·弗曼（Ethan Furman）同意達普拉諾（D'Aprano）的意見，但是維克托·斯汀納（Victor Stinner）強烈贊成元組引數的想法，只不過，他還想知道當傳入的元組有空字串時，會怎么處理，根據 PEP 提議，在處理元組時遇到空字串（實際上可以匹配任何內容）只會回傳原始字串，這會導致令人驚訝的結果：
cutsuffix("Hello World", ("", " World")) # 回傳 "Hello World"
cutsuffix("Hello World", (" World", "")) # 回傳 "Hello"
這個例子不太明顯；詞綴不一定是硬編碼的，因此空字串可能會溜進意想不到的位置，Stinner 建議如果遇到空字串，則拋出 ValueError，類似于 str.split()，但是 Sweeney 決定完全洗掉元組引數功能，以便“允許對此有更強見解的人在另外的 PEP 中提出并捍衛一系列的語意”，他在 3 月 28 日發布了該 PEP 的最新版本，
4 月 9 日，Sweeney 發起了一個指導委員會 issue，請求對其 PEP 進行評審，4 月 20 日，Stinner 代表委員會接受了該提案，
這是一個很小的更改，但值得花時間確保它具有長期適用的介面（和語意），我們將在 Python 3.9 中看到 removeprefix() 和removesuffix()，
2、新決議器
并不令人感到驚訝的是，指導委員會已經接受了我們在 4 月中旬介紹過的 CPython 新決議器，PEP 617（“CPython 新的 PEG 決議器”）由 Python 創始人即前仁慈的獨裁者（BDFL） Guido van Rossum 以及 Pablo Galindo Salgado 和 Lysandros Nikolaou 共同提出，
它已經運行良好，并且在現有決議器的速度和記憶體使用方面提升了 10% 以內的性能，由于決議器是基于決議表達語法（PEG），因此也將簡化語言規范，CPython 現有的 LL(1) 決議器存在諸多缺點和一些 hack，新的決議器將會消除掉，
這一更改為 Python 超越 LL(1) 語法鋪平了道路，盡管現有語言并不完全是 LL(1)，這一更改不會太快，因為計劃是在 Python 3.9 的命令列中提供開關，保持現有決議器可用，
但是 Python 3.10 將洗掉現有的決議器，這可能會導致語言變更，如果做了那些更改，那么，其它的 Python 實作（例如 PyPy 和 MicroPython）就需要切換決議器的 LL(1) 實作，以便跟上語言規范的要求，這可能會使核心開發者暫停進行此類更改，
3、更多內容
我們在三月初查看了 PEP 615（“在標準庫中支持 IANA 時區資料庫”），它將在標準庫中添加一個zoneinfo 模塊，該模塊將有助于從 IANA 時區資料庫中（也稱為“Olson資料庫”）獲取時區資訊，以填充時區物件，在撰寫本文時，它看起來很順利，
在 3 月底，Paul Ganssle 請求就該 PEP 作出決議，他認為在一個有趣的時間范圍內接受它，可能會很有趣：
... 我希望（出于異想天開的原因）在 4 月 5 日（星期日）UTC 時間 02:00-04:00 或 13:00-17:30 之間接受它，因為這些時間代表著地球上某些地方的不明確時間（主要在澳大利亞），還有另一個時機，那就是在 4 月 19 日星期日 UTC 01:00-03:00 之間，這段時間在西撒哈拉是不明確的，
他意識到這可能難以實作，它當然不是優先考慮的事，指導委員會沒有錯過第二個時間窗太多；Barry Warsaw 于 4 月 20 日宣布接受該 PEP，
Python 現在將具有一種機制來訪問系統的時區資料庫，以創建和處理時區，另外，Python 軟體包索引（PyPI）中有一個 tzdata 模塊，它為缺少 IANA 資料的系統提供這些資料；它將由 Python 核心開發者維護，
PEP 593（“靈活的函式和變數注釋”）添加了一種將背景關系特定的（context-specific）元資料與函式和變數關聯的方法，實際上，type hint 注解已擠出了很多年前在 Python 3.0 中實作的 PEP 3107（“函式注釋”）中設想的其它用例，PEP 593 使用注解的（Annotated）型別提示為這些用例創建了一種新的機制，
PEP 585（“標準集合中的型別提示泛型”）提供了另一種清除方法，它將允許洗掉在 typing 模塊中維護的一組并行的型別別名，以支持泛型，例如，type.List 型別將不再需要支持諸如“dict[str,list[int]]”之類的注解（例如，一個帶有字串鍵和整數串列的值的字典），
字典“加法”的聯合操作也會是 Python 3.9 的一部分，它曾不時引起爭議，但是 2 月中旬，PEP 584（“給字典添加聯合運算子”）被 Van Rossum 推薦采納，指導委員會迅速同意了，該特性于 2 月 24 日合入，
最后一個 PEP 是 PEP 602（“Python 的年度發布周期”），如提案所書，它將發布節奏從每 18 個月更改為每年一次，但是，開發和發布周期是重疊的，因此整個功能開發需要 12 個月的時間，當第一個 Python 3.9 beta 版本發布時（即現在），Python 3.10 的功能開發就開始了，請繼續關注來年的下一輪 PEP，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/137696.html
標籤：Python
上一篇：Python--裝飾器
下一篇：01.Django-基礎