思路分析 註冊頁面需要對用戶提交的數據進行校驗，並且需要對用戶輸入錯誤的地方進行提示！ 所有我們需要使用forms組件搭建註冊頁面！ 平時我們書寫form是組件的時候是在views.py裡面書寫的， 但是為了接耦合，我們需要將forms組件都單獨寫在一個地方，需要用的時候導入就行！ 例如,在項目文件 ...
按照發佈計劃，Python 3.11.0 將於 2022 年 10 月 24 日發佈。
據測試，3.11 相比於 3.10，將會有 10-60% 的性能提升，這個成果主要歸功於“Faster CPython”項目，即“香農計劃”。
關於“香農計劃”的詳情，可查看 Python 之父的主題分享，以及他的一則播客訪談。
3.11 版本為 Python 的提速開了一個激動人心的好頭。接下來，3.12 還會有更多動作。
以下文章翻譯自“香農計劃”的《Python 3.12 Goals》，大家先一睹為快吧！
作者：Mark Shannon
譯者：豌豆花下貓@Python貓
英文：https://github.com/faster-cpython/ideas/wiki/Python-3.12-Goals
本文內容可能會改動，以實際版本為準！
本文是 Faster CPython 計劃在 3.12 中實現的主要內容的概要。
跟蹤優化器
Python 3.11 提升速度的主要方法是用更快的與上下文相關的操作碼（自適應的專門化操作碼）替換個別的操作碼，下一個大的改進方法是優化多個操作碼的運行。
為此，現有的許多高級操作碼將被替換成低級操作碼，例如，用於檢查版本號和引用計數的操作碼。這些更簡單的操作碼更容易進行優化，例如，可以刪除冗餘的引用計數操作。
這些更底層的操作碼還能讓我們得到一組適合用於生成機器代碼的指令（在 CPython 和第三方 JIT 項目中都適用）。
為了做到這點，解釋器迴圈（interpreter loop）將基於聲明性的描述而生成。
這可減少一部分為了保持解釋器迴圈與某些相關函數同步而產生的 bug（mark_stacks、stack_effect 等函數），同時也讓我們可以對解釋器迴圈作較大的更改試驗。
多線程並行
Python 當前每個進程有一個全局解釋器鎖（GIL），阻礙了多線程的並行。
PEP-684：https://peps.python.org/pep-0684
PEP-554：https://peps.python.org/pep-0554
PEP-684 提出了一個方案，即保證所有的全局狀態都是線程安全的，並移動到每個子解釋器的全局解釋器鎖中使用。
PEP-554 提出了讓 Python 創建子解釋器的方案（目前只是一個 C API 特性），從而實現真正的多線程並行。
Python貓註：PEP-554 早在 2017 年就提出了，目標是落地在 Python 3.8-3.9 版本，然而事與願違。早在 2019 年的時候，我還翻譯了一篇《Has the Python GIL been slain?》。屠刀已揮出，讓它再飛一會~~
更多專門化
我們分析了哪些位元組碼將從專門化中獲益最多，計劃在 3.12 完成其餘的高收益的改進。
較小的對象結構
有許多可以減少 Python 對象結構大小的機會。由於它們被頻繁使用，這不僅有利於總體的記憶體使用，還有利於緩存的一致性。我們計劃在 3.12 中實現最有希望的一些想法。
這裡有一些向後相容性與性能之間的權衡問題，可能需要提出一個 PEP 來建立共識。
減少記憶體管理的開銷
我們不僅會減小對象的大小，還會使它們的 layout 更加規則。
這不僅能優化記憶體的分配及釋放，還能在 GC 和重新分配期間加快遍歷對象的速度。
API 穩定性
除了前述項目外，開發團隊還將提升 CPython 代碼庫的整體質量：
- 通過減少不同編譯階段的耦合，使編譯器更易於維護與測試。
- 積極地在 C 語言級別監控和改進 CPython 測試套的代碼覆蓋率。
- 改進 Python 性能基準測試套，加入更具代表性的現實世界的負載測試。
- 協助處理 CPython 問題和 PR，特別是與性能有關的問題。
- 增加用於標準基準測試的機器，增加 macOS 和 Windows 的測試結果。
- 繼續跟主要的深度使用 Python 內核的項目合作，幫助它們適配 CPython 解釋器的更改。
註：文中圖片為譯者所加。
首發於 Python貓 ，如需轉載，請聯繫作者
知乎：Python貓
博客園：豌豆花下貓
掘金：豌豆花下貓
CSDN：Python貓
