python / python/cpython

__debug__ enhancement and parse time constants

未關閉
#100,339 3 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

interpreter-core type-feature
主要語言
Python
星號
77.2k
分支
36k
PR 合併指標
PR 指標待擷取

描述

In the spirit of the efforts being made by the faster-cpython team to improve performance, I think there is some low hanging fruit it terms of improving runtime performance by... not running code in the first place, since the fastest code is the one that never runs!

The lowest of all the hanging fruits would be turning debug into an int, allowing it to take on multiple values and as such allowing multiple debug levels to checked for. This would require minimal change to the codebase and command line option to support a number after the -O argument and the same number being stored for the .opt part of the .pyc files, i.e. -O3 would replace __debug__ with 3 instead of the current bool approach. This approach would allow developers to write as much debug code as they need, while also having it get compiled out completely when it's no needed, as opposed to the current approach of toggling if 0: blocks everywhere or commenting out the different tiers of debug code when not in use.

if __debug__:
    print("Debug mode")
if __debug__ >= 2:
    print("Verbose debug mode")
if __debug__ >= 3:
    print("Paranoid debug mode")

And while that would already bring a lot of value by itself with minimal changes, the natural extension to it is actual compile time constants, i.e. __debug__ but with different names, which would make things a lot more readable. This fruit is a few branches higher on the tree. One approach to implementing these compile time constants would be to add a const keyword which declares all the compile time constants used in the file, which would be used for syntax error purposes. And during compilation they would get turned into an actual constant similarly to __debug__, with the caveat that consts would evaluate to False if not explicitly defined. As to how they would be defined, might as well use the -O option again, i.e. -OFOO would define FOO as True during compilation, i.e.:

const FOO, BAZ

# Only one of the code paths should remain, based on whether -OFOO was passed when running python
if FOO:
    print("Foo defined")
else:
    print("Foo not defined")

# If not declared by -OBAZ, should be treated as False and the if should be compiled out completely
if BAZ:
    print("We got baz")

This change would also require changes to the .pyc files, either by storing a hash/all the compile time constants used in the file itself, or just generating a completely different .pyc with a hash of all the compile time constants in place of the .opt part of the filename.


And the natural extension to that would be supporting integer constants similar to the debug extension, or better yet and builtin type -- int, float or string (constants only of course). These again require a change to the command line option in the form of -OFOO=3, but if the previous two changes are implemented, shouldn't require too much compiler changes.


All of these changes combined would more of less bring python on par with C's #if/#ifdef statements and allow for copious amounts of debug code to remain in the codebases with zero cost for the (optimized) runtime, while only incurring a small overhead for the startup (unless already cached).

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

研究方向

首先追蹤 CPython 對 -O 命令列參數的處理、debug 的編譯,以及 issue 中描述的 .pyc .opt 中繼資料。將提議的除錯層級、宣告的 compile-time 常數和具型別常數與編譯器及快取的需求進行比較;要視為完成,需要就範圍達成共識,並針對已接受的行為完成實作。

由索引模型根據 Issue 內容生成。

評估

技術堆疊
python
領域
compilers
Issue 類型
功能
難度
5/5
預估耗時
一週以上
活躍度
停滯
描述清晰度
需要釐清
新手友好度
20/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。