penguinWWY

个人最喜欢用的是 py-spy

不少都是强行找理由
某些问题就是设计的菜或者个人口味问题

@learningman 需要环境变量 CODON_PYTHON ，用来指定 libpython

看了下 Codon 的实现，目前只能算是个玩具
这个思路有点像前几年在 js 上做 Code smells and type analysis —— 只要用户写出非常易于优化的代码，我就可以优化的非常好。

@XVXVXXX 这个回家，莫名觉得很有气势

啃龙书没啥意义。
如果你想整体了解编译，不要在 parser 上浪费时间，parser 是一个非常“符合直觉”的事情，本质上就是如何把一段文本变成结构化的数据，所以不要被各种名词唬住，自己写一个简单的表达式解析器，就能大概明白了。同时 parser 在整个编译过程中只占了很小的一部分，基本没啥值得关注的东西。

编译整体看是一个不断 lower （ desuger ）的过程，用简单代替复杂，具体代替抽象。所以整体看的话，你需要大概了解一下体系结构和指令集，也就是编译的终点是什么样的。中间的过程不管是 AST 也好，IR 也好，no-target machine code 还是 target machine code ，从认知上来讲，都不是必须的（你完全可以设计一个非常简单的表达式语言，然后直接翻译成汇编指令），这些步骤只是为了满足某种需求（ native code or Interpreter ？ JIT or AOT ？ interprocedural or intraprocedural ？）而增加的、便于使用的中间层。

明确输入（语言、特性、功能）和输出（目标指令集），剩下的就是取舍和拼接。现在编译体系复杂之处在于为了某些目标（性能、功能、复杂的语言特性）而在不同层次间不得不产生耦合，使用某些约定（而不是设计）。当这种情况越多，原本清晰的结构就会变成一坨。。。

写新的 test ，或者写一些方便 debug 、处理日志的小脚本

list 生命周期结束的时候会调用 list_dealloc 函数，但并不会立即释放内存。而是存放在对应的 free list 中，如果有新的大小合适的 list 生成则会直接使用，减少内存分配和释放的消耗。

print(id([])); print(id([]))

两次分配的 list 是同一个指针，所以 id 相同。debug 模式是通过 trace 实现的，中间有别的 list 生成（或释放），所以没有使用到同一个指针，id 不同