Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Code run with -c or a "code" launch gets __name__ == "builtins" instead of "__main__"

未关闭
  • 哪里不对？
#2,079 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

@Om-singhaI 已经在做这个了。

开始于 2026年10月6日。

  • #2080 来自 @Om-singhaI —— 未关闭

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
35/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
停滞
技术栈
python
领域
backend

调研方向

Start with run_code() in src/debugpy/server/cli.py and the CLI tests in tests/debugpy/server/test_cli.py; compare its execution setup with run_file() using runpy.run_path(). Run the focused CLI tests and reproduce with python3 -m debugpy --listen 127.0.0.1:0 -c "$CODE". Done when code runs with __name__ == "__main__", its main block runs, and the reported pickling failure is covered by a test.

由索引模型根据 Issue 内容生成。

描述

Before creating a new issue, please check the FAQ to see if your question is answered there.

Environment data

  • debugpy version: 1.8.22+3.g751502d (running from source at 751502d, current main)
  • OS and version: macOS 26.6.2 (25G83)
  • Python version (& distribution if applicable, e.g. Anaconda): CPython 3.10.6 from python.org, and 3.14.3 from Homebrew
  • Using VS Code or Visual Studio: neither. I used the CLI, and also a "code" launch sent straight to the adapter.

Actual behavior

Code passed with -c, or with "code" in a launch configuration, doesn't run as __main__. __name__ is "builtins", so an if __name__ == "__main__": block is skipped, and a class the code defines can't be pickled:

__name__ = builtins
pickle failed: Can't pickle <class 'Point'>: attribute lookup Point on builtins failed

That is from 3.10.6. 3.14.3 gives the same result, with the pickle error worded as it's not found as builtins.Point.

run_code() in src/debugpy/server/cli.py ends with eval(code, {}). That globals dict has no __name__, so the name is looked up in builtins and comes back as "builtins". A class the code defines gets that as its __module__, which is where pickle then looks for it. A file target doesn't have this problem, because run_file() uses runpy.run_path(target, run_name="__main__"), which puts a temporary __main__ module in place.

A "code" launch goes through the same function, since the adapter turns it into a -c argument for the debugpy CLI in the debuggee. With "code": ["print('__name__ is', __name__)", "if __name__ == '__main__':", " print('main block ran')"] and "console": "internalConsole", the debuggee prints __name__ is builtins and nothing else.

Expected behavior

The same as python -c:

__name__ = __main__
main block ran
pickle ok

Steps to reproduce:

CODE='import pickle
class Point: pass
print("__name__ =", __name__)
if __name__ == "__main__":
    print("main block ran")
try:
    pickle.dumps(Point()); print("pickle ok")
except Exception as e:
    print("pickle failed:", e)'

python3 -c "$CODE"
python3 -m debugpy --listen 127.0.0.1:0 -c "$CODE"

The first command prints the expected output above and the second prints the actual output. Nothing needs to attach; the code runs right away because --wait-for-client isn't given.

I have a fix and can open a PR. It runs the code in a temporary __main__ module, the same way run_path() does for a file, and adds a test to tests/debugpy/server/test_cli.py.

主要语言
Python
星标
2.5k
派生
205
平均合并
1 天 9 小时
30 天内合并 PR
3

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

microsoft/debugpy 的其他 Issue

查看 microsoft/debugpy 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。