
來自TIOBE的最新10月份統計資料顯示,Python首次超越Java、JavaScript、C語言等,成為最受歡迎的編程語言,TIOBE過去20年一直在追蹤編程語言的受歡迎程度,其資料來自于對25個搜索引擎和網站的檢索結果,包括但不限于谷歌、必應、維基百科、雅虎、油管等,Python最近的份額占比是11.27%,C語言是11.16%,Java以10.4排第三;TOP10中還有C++、C#、Visual Basic、JavaScript、SQL、PHP和Assembly,

2021年10月04日,Python官方發布了最新穩定版本3.10.0 ,它包含許多新的特性和優化,從今天發布的中文版《What’s New in Python(2021.10.15)》摘抄了部分重點如下:
1 摘要 -- 發布重點
新的語法特性:
? PEP 634, 結構化模式匹配: 規范說明
? PEP 635, 結構化模式匹配: 動機與理由
? PEP 636, 結構化模式匹配: 教程
? bpo-12782,加圓括號的背景關系管理器現在正式被允許使用,
標準庫中的新特性:
? PEP 618,向 zip 添加可選的長度檢查,
解釋器的改進:
? PEP 626,在除錯和其他工具中使用精確的行號,
新的型別標注特性:
? PEP 604,允許 X | Y 形式的聯合型別寫法
? PEP 613,顯式型別別名
? PEP 612,形參規格變數
重要的棄用、移除或限制:
? PEP 644,要求 OpenSSL 1.1.1 或更新的版本
? PEP 632,棄用 distutils 模塊,
? PEP 623,棄用并準備移除 PyUnicodeObject 中的 wstr 成員,
? PEP 624,移除 Py_UNICODE 編碼器 API
? PEP 597,增加可選的 EncodingWarning
2 新的特性
2.1 帶圓括號的背景關系管理器
現在已支持使用外層圓括號來使多個背景關系管理器可以連續多行地書寫,這允許將過長的背景關系管理器集能夠以與之前 import 陳述句類似的方式格式化為多行的形式,
2.2 更清楚的錯誤訊息
SyntaxError
IndentationError
AttributeError
NameError
2.3 PEP 626:在除錯和其他工具中使用精確的行號
PEP 626 帶來了更精確可靠的行號用于除錯、性能分析和測驗工具,所有被執行的代碼行都會并且只有被執行的代碼行才會生成帶有正確行號的追蹤事件,
幀物件的 f_lineno 屬性將總是包含預期的行號,
代碼物件的 co_lnotab 屬性已被棄用并將在 3.12 中被移除,需要從偏移量轉換為行號的代碼應改用新的 co_lines() 方法,
2.4 PEP 634:結構化模式匹配
增加了采用模式加上相應動作的 match 陳述句和 case 陳述句的形式的結構化模式匹配,模式由序列、映射、基本資料型別以及類實體構成,模式匹配使得程式能夠從復雜的資料型別中提取資訊、根據資料結構實作分支,并基于不同的資料形式應用特定的動作,
match 陳述句接受一個運算式并將其值與以一個或多個 case 陳述句塊形式給出的一系列模式進行比較,具體來說,模式匹配的操作如下:
1. 使用具有特定型別和形狀的資料 (subject)
2. 針對 subject 在 match 陳述句中求值
3. 從上到下對 subject 與 case 陳述句中的每個模式進行比較直到確認匹配到一個模式,
4. 執行與被確認匹配的模式相關聯的動作,
5. 如果沒有確認到一個完全的匹配,則如果提供了使用通配符 _ 的最后一個 case 陳述句,則它將被用作已匹配模式,如果沒有確認到一個完全的匹配并且不存在使用通配符的 case 陳述句,則整個 match 代碼塊不執行任何操作,
2.5 可選的 EncodingWarning 和 encoding="locale" 選項
TextIOWrapper 和 open() 的默認編碼格式取決于具體的平臺和語言區域設定,由于 UTF-8 被用于大多數 Unix 平臺,當打開 UTF-8 檔案 (例如 JSON, YAML, TOML, Markdown) 時省略 encoding 選項是一個非常常見的錯誤,
3 有關型別提示的新增特性
3.1 PEP 604: 新的型別聯合運算子
引入了啟用 X | Y 語法的型別聯合運算子,這提供了一種表示’ 型別 X 或型別 Y’ 的相比使用 typing. Union 更清晰的方式,特別是在型別提示中,
3.2 PEP 612: 形參規格變數
在 typing 模塊中新增了兩個選項以改進用于 PEP 484 的 Callable 提供給靜態型別檢查器的資訊,第一個選項是形參規格變數,它們被用來將一個可呼叫物件的形參型別轉發給另一個可呼叫物件——這種模式常見于高階函式和裝飾器,使用示例可在 typing.ParamSpec 中找到,在之前版本中,沒有一種簡單辦法能以如此精確的方式對形參型別的依賴性進行型別標注,
第二個選項是新的 Concatenate 運算子,它與形參規格變數一起使用以便對增加或移除了其他可呼叫物件的高階可呼叫物件進行型別標注,使用示例可以在 typing.Concatenate 中找到,
3.3 PEP 613: 型別別名
PEP 484 引入了型別別名的概念,只要求它們是不帶標注的最高層級賦值,這種簡單性有時會使得型別檢查器難以區分型別別名和普通賦值,特別是當涉及到前向參考或無效型別的時候,
3.4 PEP 647: 用戶自定義的型別保護器
TypeGuard 已被添加到 typing 模塊用來標注型別保護器函式并改進在型別細化期間提供給靜態型別分析器的資訊,
4 其他語言特性修改
? int 型別新增了一個方法 int.bit_count(),回傳給定整數的二進制展開中值為一的位數,或
稱“位元計量”,(由 Niklas Fiekas 在 bpo-29882 中貢獻,)
? 現在 dict.keys(), dict.values() 和 dict.items() 所回傳的視圖都有一個 mapping 屬性,
它給出包裝了原始字典的 types.MappingProxyType 物件,(由 Dennis Sweeney 在 bpo-40890 中
貢獻,)
? PEP 618: 現在 zip() 函式有一個可選的 strict 旗標,用于要求所有可迭代物件的長度都相等,
? 接受整數引數的內置和擴展函式不再接受 Decimal, Fraction 以及其他可被轉換為整數但會丟
失精度(即具有 __int__() 方法但沒有 __index__() 方法)的物件,(由 Serhiy Storchaka 在
bpo-37999 中貢獻,)
? 如果 object.__ipow__() 回傳 NotImplemented,該運算子將正確地按照預期回退至
object.__pow__() 和 object.__rpow__(),(由 Alex Shkop 在 bpo-38302 中貢獻,)
? 現在賦值運算式可以不帶圓括號地在集合字面值和集合推導式中使用,也可以在序列索引號中使
用(但不能用于切片),
? 函式具有一個新的 __builtins__ 屬性,當函式被執行時它會被用于查找內置符號,而不是在
__globals__['__builtins__'] 中查找,如果 __globals__["__builtins__"] 存在則該
屬性將基于它來初始化,否則將基于當前的內置函式,(由 Mark Shannon 在 bpo-42990 中貢獻,)
? 增加了兩個新的內置函式——aiter() 和 anext() 以分別提供與 iter() 和 next() 對應的異
步版本,(由 Joshua Bronson, Daniel Pope 和 Justin Wang 在 bpo-31861 中貢獻,)
13? 靜態方法 (@staticmethod) 和類方法 (@classmethod) 現在會繼承方法屬性 (__module__,
__name__, __qualname__, __doc__, __annotations__) 并具有一個新的 __wrapped__ 屬
性,此外,靜態方法現在還是與常規函式一樣的可呼叫物件,(由 Victor Stinner 在 bpo-43682 中貢
獻,)
? 復雜目標的注解(PEP 526 定義的除 simple name 之外的一切復雜目標)在運行時不再受 from
__future__ import annotations 的影響,(由 Batuhan Taskaya 在 bpo-42737 中貢獻),
? 類和模塊物件現在可以按需創建空的注解字典,為保證向下兼容,這些注解資料將存盤于物件的
__dict__ 中,這改進了 __annotations__ 的最佳用法;更多資訊請參閱 annotations-howto ,(由
Larry Hastings 在 bpo-43901 中貢獻)
? 由于會產生副作用,現在 from __future__ import annotations 時禁止使用包含 yield 、
yield from 、 await 或已命名運算式的注解,(由 Batuhan Taskaya 在 bpo-42725 中貢獻)
? 未系結變數、 super() 和其他可能改變符號表處理的運算式,現在在 from __future__ import
annotations 時不能用作注解,(由 Batuhan Taskaya 在 bpo-42725 中貢獻)
? float 型別和 decimal.Decimal 型別的 NaN 值的哈希值現在取決于物件身份,以前,即便 NaN
值彼此不等,也都是哈希為 0,在創建包含多個 NaN 的字典和集合時,由于哈希沖突過度,導致
了運行代價可能會二次方增長,(由 Raymond Hettinger 在 bpo-43475 中貢獻)
? A SyntaxError (instead of a NameError) will be raised when deleting the __debug__ constant. (Contributed by Dong-hee Na in bpo-45000.)
? SyntaxError exceptions now have end_lineno and end_offset attributes. They will be None if
not determined. (Contributed by Pablo Galindo in bpo-43914.)
5 新增模塊
? 無,
6 改進的模塊
6.1 asyncio
6.2 argparse
6.3 array
6.4 asynchat、 asyncore 和 smtpd
6.5 base64
6.6 bdb
6.7 bisect
6.8 codecs
6.9 collections.abc
6.10 contextlib
6.11 curses
6.12 dataclasses
6.13 distutils
6.14 doctest
6.15 encodings
6.16 fileinput
6.17 faulthandler
6.18 gc
6.19 glob
6.20 hashlib
6.21 hmac
6.22 IDLE 與 idlelib
6.23 importlib.metadata
6.24 inspect
6.25 linecache
6.26 os
6.27 os.path
6.28 pathlib
6.29 platform
6.30 pprint
6.31 py_compile
6.32 pyclbr
6.33 shelve
6.34 statistics
6.35 site
6.36 socket
6.37 ssl
6.38 sqlite3
6.39 sys
6.40 _thread
6.41 threading
6.42 traceback
6.43 types
6.44 typing
6.45 unittest
6.46 urllib.parse
6.47 xml
6.48 zipimport
7 性能優化
? 現在,建構式 str() 、 bytes() 和 bytearray() 速度更快了(小物件大約提速 30-40%),(由Serhiy Storchaka 貢獻于 bpo-41334 )
? 現在, runpy 匯入的模塊變少了, python3 -m module-name 命令的啟動時間平均加快 1.4 倍,
在 Linux 上, Python 3.9 的 python3 -I -m module-name 匯入了 69 個模塊,而 Python 3.10 只匯入了 51 個模塊(少了 18 個),(由 Victor Stinner 貢獻于 bpo-41006 和 bpo-41718)
? 現在, LOAD_ATTR 指令會使用新的“單獨操作碼快取”機制,對于常規屬性大約會提速 36%,而對于槽位屬性會加快 44%,(由 Pablo Galindo 和 Yury Selivanov 貢獻于 bpo-42093 ),并由 Guido van
Rossum 貢獻于 bpo-42927,基于最初在 PyPy 和 MicroPython 中實作的思路,)
? 現 在, 當 用 --enable-optimizations 構 建 Python 時, 會 在 編 譯 和 鏈 接 命 令 行 中 添
加 -fno-semantic-interposition, 這 會 讓 用 帶 參 數 --enable-shared 的 gcc 構 建
Python 解釋器時提速 30%,詳情請參閱 ‘這篇文章https://developers.redhat.com/blog/2020/06/25/
red-hat-enterprise-linux-8-2-brings-faster-python-3-8-run-speeds/>‘_ ,(由 Victor Stinner 和 Pablo Galindo貢獻于 bpo-38980 )
? bz2 / lzma / zlib 模 塊 用 了 新 的 輸 出 緩 沖 區 管 理 代 碼, 并 在 _compression.
DecompressReader 類中添加 “.readall()“ 函式,現在, bz2 解壓程序提速了 1.09 倍 ~ 1.17 倍,lzma 解壓快樂 1.20 倍 ~ 1.32 倍, GzipFile.read(-1) 快了 1.11 倍 ~ 1.18 倍,(由 Ma Lin 貢獻,由 Gregory P. Smith 審查, bpo-41486)
? 在使用字串式的注解時,函式的注解字典不再是在函式創建時建立了,取而代之的是,注解被存盤為一個字串元組,而函式物件在需要時再延遲轉換為注解字典,這一優化將定義帶注解函式的CPU 時間減少了一半,(由 Yurii Karabas 和 Inada Naoki 貢獻于 bpo-42202)
? 現在,子串搜索函式,如 str1 in str2 和 str2.find(str1) ,有時會采用 Crochemore & Perrin
的“二路歸并”字串搜索演算法,以避免長字串的二次檢索行為,(由 Dennis Sweeney 貢獻于bpo-41972 )
? 為 _PyType_Lookup() 加入了少許優化,以提高型別屬性快取查詢在常見命中情況下的性能,這使得解釋器的平均速度提高了 1.04 倍,(由 Dino Viehland 貢獻于 bpo-43452 )
? 現在,以下內置函式支持更快的 PEP 590 vectorcall 呼叫約定: map() 、 filter() 、 reversed() 、bool() 和 float() ,(由 Dong-hee Na 和 Jeroen Demeyer 貢獻于 bpo-43575 、 bpo-43287 、 bpo-41922、 bpo-41873 和 bpo-41870 )
? 通過移除內部的 RLock , BZ2File 的性能得以改善,這使得 BZ2File 在面對多個同時讀寫執行緒時變得不再安全,類似一直如此的 gzip 和 lzma 中的對應類,(由 Inada Naoki 貢獻于 bpo-43785 )
一起發布的內容還有棄用、移除、移植、位元組碼、編譯、API等方面的內容,略,
Python 3.10.0 官方下載地址
| Version | Operating System | File Size |
|---|---|---|
| Gzipped source tarball | Source release | 25007016 |
| XZ compressed source tarball | Source release | 18726176 |
| macOS 64-bit universal2 installer | macOS for macOS 10.9 and later | 39741684 |
| Windows embeddable package (32-bit) | Windows | 7521592 |
| Windows embeddable package (64-bit) | Windows | 8474319 |
| Windows help file | Windows | 9559706 |
| Windows installer (32-bit) | Windows | 27194856 |
| Windows installer (64-bit) | Windows | 28315928 |
注:Python從3.9+開始已不支持 Windows7及更早版本,
Python 3.10.0 安裝和運行


以下是我的嘗鮮操作演練:
IDLE視窗的操作提示符移動編輯框外
與3.8.8版本相比,陳述句的縮進對齊一目了然

終于引進了:分支結構陳述句
不是switch-case, select-case等,而是 match-case
def fib(n):
match n:
case 1|2:
return 1
case other:
return fib(n-1)+fib(n-2)
for i in range(1,11):
print(fib(i))
1
1
2
3
5
8
13
21
34
55
其中"case other:" 里的other并非關鍵字,但可能就是相當于其他編程語言中的 case else 或 otherwise 或 default 等等,它可以任意寫但效果相同,如下:
def fib(n):
match n:
case 1|2:
return 1
case anything:
return fib(n-1)+fib(n-2)
fib(5)
5
fib(10)
55
注:官方舉例使用開線:“ case _ : ”
一個奇怪的小發現
怎么會有賦值功能?
i = 5
match i:
case 1: print(1)
case 2: print(2)
case i: print(i**2)
25
match i:
case 1: print(1)
case 2: print(2)
case n: print(i**2)
25
match i:
case 1: print(1)
case 2: print(2)
case n: print(n**2)
25
match i:
case 1: print(1)
case 2: print(2)
case i: print(n**2)
25
match i:
case 1: print(1)
case 2: print(2)
case a: print(i**2)
25
match i:
case 1: print(1)
case 2: print(2)
case i: print(a**2)
25
a
5
b
Traceback (most recent call last):
File "<pyshell#15>", line 1, in <module>
b
NameError: name 'b' is not defined
match i:
case 1: print(1)
case 2: print(2)
case b: print(i**2)
25
b
5
另一個小發現
這算不算bug,還是疏忽了沒更新?新版本中關鍵字 match case 已加亮標注,黃色加亮已是關鍵字的待遇,但是內置庫keyword中的kwlist串列還沒有添加進去,

幫助檔案也還沒有match和case的內容
help('if')
The "if" statement
******************
The "if" statement is used for conditional execution:
if_stmt ::= "if" assignment_expression ":" suite
("elif" assignment_expression ":" suite)*
["else" ":" suite]
It selects exactly one of the suites by evaluating the expressions one
by one until one is found to be true (see section Boolean operations
for the definition of true and false); then that suite is executed
(and no other part of the "if" statement is executed or evaluated).
If all expressions are false, the suite of the "else" clause, if
present, is executed.
Related help topics: TRUTHVALUE
help('return')
The "return" statement
**********************
return_stmt ::= "return" [expression_list]
"return" may only occur syntactically nested in a function definition,
not within a nested class definition.
If an expression list is present, it is evaluated, else "None" is
substituted.
"return" leaves the current function call with the expression list (or
"None") as return value.
When "return" passes control out of a "try" statement with a "finally"
clause, that "finally" clause is executed before really leaving the
function.
In a generator function, the "return" statement indicates that the
generator is done and will cause "StopIteration" to be raised. The
returned value (if any) is used as an argument to construct
"StopIteration" and becomes the "StopIteration.value" attribute.
In an asynchronous generator function, an empty "return" statement
indicates that the asynchronous generator is done and will cause
"StopAsyncIteration" to be raised. A non-empty "return" statement is
a syntax error in an asynchronous generator function.
Related help topics: FUNCTIONS
help('match')
No Python documentation found for 'match'.
Use help() to get the interactive help utility.
Use help(str) for help on the str class.
help('case')
No Python documentation found for 'case'.
Use help() to get the interactive help utility.
Use help(str) for help on the str class.
一起學習 PYTHON 的交流Q碼地址: http://qr01.cn/FHYKEa

轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/317938.html
標籤:python
