gaogaotiantian

@moudy 所以是为啥？

@kneo 是只读的，肯定没办法在这个节点继续往下运行，但是是可以做基本的 evaluation 的。就是没办法接着跑程序（ continue ）了，但是你可以对现在的变量做一些 evaluation ，有时候可能对 debug 有点帮助。

@kneo 没有已知的限制，这是不用 pickle 最大的好处。我现在还不太能想象在什么情况下无法产生 dump 。但是这个 dump 是没办法还原全部信息的。最基本的，你还原的 custom object 是没有 method 的，你无法调用它的 method 。你可以简单地理解为，我把所有的 python object 都看做一个只有一些 attribute 的普通 object ，然后把这些 attribute 保存。好处就是，我可以保存所有的 object 。坏处就是，它们还原是不充分的。

这是个思路和方向问题，我的思路是 dump 应该永远工作，能不能还原再说。

@w568w 是，怎么保存极大量的信息是一个难度很大的事情，但是你说的这个是 time travel debugging ，是另一个级别的东西了~相当于我这个是一帧，那个是一个电影。

我好像完成了楼里提出的所有条件
* 修改 CPython 代码
* 贡献 PEP
* 成为 core dev
* 在 pycon 上做 talk

如果你想尝试给 CPython 贡献点代码，其实没有那么难，可以参考一下我当时第一个 PR 的视频（ https://www.bilibili.com/video/BV1Ck4y1h7Hm/），你应该可以发现，这个 bug ，其实很多人都可以解决，它不是一个非常深奥的事情。

相对来说，成为 CPython 团队成员难度更大的应该是持之以恒的动力。改第一个 bug 的时候你可能很亢奋，到第二个，第三个，第四个的时候，就没那么激动了。而且你很快就会意识到，你非常兴奋地完成的修改，可能没有人 review ，甚至有 core dev 告诉你你这个方向不对，直接 close 掉。你会有不少精力花在沟通上，也会有一些努力付诸东流。然而这是成为一个大型项目贡献者必然要经历的过程，也是学习的过程（比如你做的这个东西，为什么它不适合 CPython ）。

说回你的问题，我觉得“专家”这个词，它本身是带有主观色彩的，每个人的观点都不一样。比如这 20 层楼里出现的几个条件的交集，全中国只能交出我一个人来。但是你能说全中国就我一个 Python 专家么？

甚至，你能说我是 Python 专家么？

我基本不说我是 Python 专家，就是略懂。因为 CPython 发展到现在，已经是一个比较大的项目了，几乎没有人可以对所有的领域都了解的足够透彻。我自己敢说我是“专家”的领域，只有 pdb 和 tracing 的部分。其他的地方很多我也是遇到问题现学，甚至是没能力解决。

所以我觉得，没必要纠结“专家”这个名头，是不是“专家”没那么重要，关键是你的 Python 能力能不能解决你的实际需求。你如果是要处理一些数据，就去了解数据怎么处理，不需要知道 CPython 内部是如何工作的。如果你要写个网站，就去写网站，不需要知道 copy-and-paste JIT 的原理是什么。

如果你和我一样是一个爱慕虚荣的人，那就花点时间和精力，去混个 core dev 的名头，偶尔还能和小伙伴显摆一下，也不错：）

@no1xsyzy VizTracer 提供的图确实有和火焰图很相似的地方。简单来说，火焰图是一个“总结”性的图，它展示的是某一个函数在这个位置占据的总时间。而 VizTracer 的图是每一次调用都会有一个展示。

比如说，A 调用了 B 100 次，每次 1ms 。在火焰图上，就是最下面是 A，A 的宽度是 100ms 的 B 加上 A 自己的耗时，A 上面有一个 B，B 的宽度是 100ms 。而 VizTracer 的图上，最下面是 A，A 上面有 100 个 1ms 的 B，每个 B 之间的间隔就是他们被调用之间 A 的耗时。

@frostming 这是个挺好的建议……我这两天就弄一下，把--run 作为 undocumented feature （为了 backward compatibility ），然后用--为主。

@THP301 谢谢如此高的评价啊~实用性和易用性确实是我做这个项目时候很期望达成的目标~

@no1xsyzy 哈~这个不是火焰图，算是 call stack 图吧~核心展示内容是函数之间的调用次序和时间