Python3.12正式發(fā)布了
作者大部分時(shí)間周更，為了不錯(cuò)過精彩內(nèi)容，請點(diǎn)擊上方“Python碎片 ”，“ 星標(biāo) ”公眾號
文章來源 ：OSC開源社區(qū)（ID：oschina2013)
Python 3.12.0 正式發(fā)布穩(wěn)定版。
主要變化
-
更靈活的 f-string 解析 (PEP 701)
-
支持 buffer 協(xié)議 (PEP 688)
-
引入新的 debugging/profiling API (PEP 669)
-
支持具有單獨(dú)全局解釋器鎖的獨(dú)立子解釋器 (PEP 684)
-
優(yōu)化性能，例如 PEP 709 和對 BOLT 二進(jìn)制優(yōu)化器的支持，預(yù)計(jì)總體性能提高 5%
-
改進(jìn)錯(cuò)誤信息
-
支持 Linux perf 分析器在跟蹤過程中報(bào)告 Python 函數(shù)名稱
類型注釋
-
為泛型類引入新的類型注釋語法 (PEP 695)
-
為方法引入新的 override 裝飾器 (PEP 698)
下面簡單介紹值得關(guān)注的變化：
更靈活的 f-string 解析 (PEP 701)
新版取消了最初制定 f-strings 時(shí)制定的一些限制。經(jīng)過這些變化，使得 f-strings 更加統(tǒng)一，成為一種可以直接整合到解析器中的正式化語法。這將會為終端用戶和庫開發(fā)者帶來較大優(yōu)勢，同時(shí)也大大降低用于解析 f-strings 代碼的維護(hù)成本。
最初設(shè)置 f-strings 限制是為了能夠在不修改現(xiàn)有詞法分析器的情況下將 f-strings 的解析實(shí)現(xiàn)到 CPython 中。但目前來看，這些限制反而帶來了復(fù)雜性。比如：
-
在表達(dá)式部分中，無法使用引號字符來界定 f-strings
>>> f'Magic wand: { bag['wand'] }'
^
SyntaxError: invalid syntax -
之前考慮過的一種解決方法會導(dǎo)致在執(zhí)行的代碼中出現(xiàn)轉(zhuǎn)義序列，這在 f-strings 中是被禁止的：
>>> f'Magic wand { bag[\'wand\'] } string'
SyntaxError: f-string expression portion cannot include a backslash -
f-strings 中無法使用注釋語法：
>>> f'''A complex trick: {
... bag['bag'] # recursive bags!
... }'''
SyntaxError: f-string expression part cannot include '#' -
許多其它語言表達(dá)式字符串插值都支持不擴(kuò)展轉(zhuǎn)義序列的任意嵌套。比如：
# Ruby
"#{ "#{1+2}" }"
# JavaScript
`${`${1+2}`}`
# Swift
"\("\(1+2)")"
# C#
$"{$"{1+2}"}"
Python 團(tuán)隊(duì)意識到，從語言用戶的角度來看，這些限制沒有任何意義，所以他們目前通過賦予 f-strings 字面量一個(gè)沒有例外的常規(guī)語法，并使用專用的解析代碼來實(shí)現(xiàn)它，從而消除這些限制。
f-strings 的另一個(gè)問題是，CPython 中的當(dāng)前實(shí)現(xiàn)依賴于將 f-strings 標(biāo)記化為 STRING 令牌，并對這些令牌進(jìn)行后處理。這帶來了以下問題：
-
它給 CPython 解析器增加了相當(dāng)大的維護(hù)成本。這是因?yàn)榻馕龃a需要手動(dòng)編寫，這在歷史上導(dǎo)致了大量的不一致性和錯(cuò)誤。在 C 中手動(dòng)編寫和維護(hù)解析代碼一直被認(rèn)為是容易出錯(cuò)和危險(xiǎn)的，因?yàn)樗枰幚泶罅康脑荚~法分析器緩沖區(qū)上的手動(dòng)內(nèi)存管理。
-
f-strings 解析代碼無法使用新的 PEG 解析器所允許的新錯(cuò)誤消息機(jī)制，這些錯(cuò)誤消息帶來的改進(jìn)已經(jīng)受到了熱烈歡迎，但因?yàn)?f-strings 用的是獨(dú)立解析器，所以無法使用上新改進(jìn)的錯(cuò)誤消息機(jī)制。另外，因?yàn)?f-strings 有幾個(gè)語法特性可能會因?yàn)樵诒磉_(dá)式部分內(nèi)部發(fā)生的不同隱式標(biāo)記化而令人困惑 （例如
f"{y:=3}"并不是一個(gè)賦值表達(dá)式） 。 -
其它 Python 實(shí)現(xiàn)無法知道它們是否正確實(shí)現(xiàn)了 f-strings，因?yàn)樗鼈儾⒉皇枪俜?Python 語法的一部分。這一點(diǎn)很重要，因?yàn)橛袔讉€(gè)知名的替代實(shí)現(xiàn)正在使用 CPython 的 PEG 解析器，如 PyPy。f-strings 使用一個(gè)獨(dú)立的解析器，阻止了這些替代實(shí)現(xiàn)利用官方語法，以及從改進(jìn)的錯(cuò)誤消息機(jī)制中受益。
期待新 f-strings 能用得更順心。
給每個(gè)子解釋器創(chuàng)建 GIL (PEP 684)
PEP-684 由“香農(nóng)計(jì)劃”的作者 Eric Snow 提出，主要是給每個(gè)子解釋器創(chuàng)建 GIL，允許 Python 實(shí)現(xiàn)真正的并行處理。
說到并行處理，目前 Python 3.12 尚未引入「no-GIL 構(gòu)建」。
按照計(jì)劃，Python 團(tuán)隊(duì)會在 Python 3.13 中將 no-GIL 構(gòu)建添加為實(shí)驗(yàn)性構(gòu)建模式。
分享
收藏
點(diǎn)贊
在看