🤔 说起来， #Python 的开发者们也真是怪纯的，不喜欢用这些杂七杂八的小技巧。
我到 GitHub 搜 "Python codegen"&lang=python ，得到的七页结果没一个是生成 Python 代码的，要么是模板系统：
https://github.com/mattduan/codegen
https://github.com/AlexFinder/CodeGen
要么是特定的模板化代码生成器：
https://github.com/siggame/Creer

看起来好像大家并不知道 Python 的动态类型可以结合上代码生成，被用来替换语言内建的调用和成员访问语法(callNew,invoke,getAttr)，从而在实现原有语义的同时做到生成代码以内联铺平内部式DSL，做到零开销抽象一样。

还有数个 Swagger REST API defs file 的生成实现…… 对了，其实我觉得 Swagger 也太纯真了，都没有受到函数式大佬们的污染，因为它"优化"后也只是支持 YAML 的缩进来"简写"深层嵌套结构而已。
我之前写过类似 Swagger 的玩意，它用的 DSL 完全不需要你写出每个参数的 - name:"WTF" - type: xxx，与之相比 Swagger 那 YAML 语法简直就像所有调用参数都要求 kwarg 的 Python 一样冗长……

其实我很好奇为什么 Swagger 有那么多语言的 codegen 实现、有那么多人实现这些实现，却没有一个人想着怎么优化它的“源语言”并提交给Swagger社区呢？（猜过分点，还是有人设计了但太烂所有没采用呢emmm）

其实这个算法并不复杂，甚至不一定可以被称为「算法」（我一直相信是因为自己智商欠缺才要那么多时间才弄好的），那么为什么没有其他工程派人士弄出一样的东西来呢？ 😟
我想可能是因为那些程序员平时不使用定义式风格，所以他们不会想办法进一步设计更广阔，以至于跨语言、跨底层框架的代码复用；如果有，那就是人太少了，或者没人同时了解一些编译原理入门(相对更专业的常量折叠/回填而言)习惯。

我真的是个定义式编程迷，我设计过的所有复用库都不包含复杂的逻辑/数字/几何/数据结构/树图算法(尽管我做梦都想)，但它们通通具有定义式的编程 API — 多数是用 vararg 尽可能在构造时就完成配置而不用如 .addXXX 的变更调用。尽管我一点也不愿意写 Haskell 和 Scala / Scheme(respect for its s-expr.) 等格调品味超高的(纯)函数式编程语言，函数式对我的影响我没照本宣科的接受，逼自己思考它们眼中的问题或是尝试实现它们那令人困惑的命名/建模方法。当然我知道放弃不值得炫耀，但这使我找到了不同于函数式但比函数式更易读、易维护的接口建模风格，就是 Kotlin 的风格和设计哲学，用于解决问题的东西就应该在平衡下解决尽可能多的问题、并且从不会制造其它问题。 #statement #design

当然如果你写代码只是为了弄出一个 "working" 的东西，或者觉得因为自己足够聪明所以 “重构甚至重写是码农做的事”、 “调试是愚蠢的”、 “把自己所知道的明确举例讲明白是为蠢人费力的无聊事” ，那就想不到你所想不到但的确可以实现的东西了。

👆🏼Last pinned

在修复了 TreeWidget.TreeItem 的 id 问题后(但它的tuple第一项就只限str了 和用UUID的效果差别大)，终于又完成对 Scale(slider) 的 TTk interval 支持移植(原版不支持的特性) ，我添加了一个简单的roundInterval查找算法解决这个库里的显示不准确问题，但目前还没能完成纵向的渲染（有一部分原因是它的代码质量太差了！水平线以下！害得我没时间写 code object cache）

https://stackoverflow.com/questions/47200625/how-to-make-ttk-scale-behave-more-like-tk-scale
https://github.com/TkinterEP/ttkwidgets/blob/master/ttkwidgets/tickscale.py#L643

就是这个家伙。 我的天哪，还有什么代码能比这个更长的吗...

虽然我写得很累，但我觉得应该改正下自己的坏脾气。 别人的代码即便不好，也是可以帮忙更改的。 虽然混乱的代码给我造成了麻烦，但他们设计逻辑也是很累的，代码质量不好不能全怪他们，也怪环境不好。

也要看我有没有能力改。

https://realpython.com/python-type-checking/#gradual-typing-and-consistent-types 草，不愧是 Python 这文章...

https://github.com/microsoft/pyright/blob/da39a2a78a442d2a6b29d664b32475c361c853f1/packages/pyright-internal/src/tests/samples/dataclass8.py
@dataclass
class BaseClass:
my_ref: "ReferredClass"
欸，有更新 data class 支持，而且还内部支持 typing 实现 gradual typing 不像 Ruby 太 duck typing 了，看来 Py 还是有点东西
https://github.com/microsoft/pyright/blob/930c2021c63531248c6a979e3d3afdbcca14f16b/packages/pyright-internal/src/analyzer/types.ts#L530
export function hasUnknownBaseClass(classType: ClassType)
欸，原来不报类型错误必须要在超类链上啊... 真是过分呢，我只是想面向对象 Mixin 啊

啊…… 看来数学不好果然难呢。 重构的时候我把 xs[a:-1] 的 exclusive end -1 省略了(那就包括末项了)、 map(it*b, round(n/b)) 给理解成 range(a, n, b) 了，我加的 while a%b != 0 查找其实就是 (a/b) *b ... 虽然都是很简单的倍数关系啊

不过，在我经历无数烂代码的洗礼后，终于找到了bug的源头(一个str属性配置没适配...) 现在终于可以移植过来了emmmm...

有意思的是这位大神作者(可惜代码质量怎么那么差) 写出的代码虽然很好用，但其实它是薛定谔程序！ 测试里应用范围内无变量，但程序行为却间隔1次时好时坏！

这个故事告诉我们，不要尝试复制粘贴自己的代码然后做出改动。多抽提出函数调用。不然出了问题会非常麻烦。(这位大佬是把 横向纵向 的所有区别代码都用 self.op = 的形式支持，这又走另一个极端了... )

不过说起来这次重构限制也蛮大的。目的只是要支持的几个控件里的一小个，因为原代码质量和工具不好 费了一天时间才移植一个 Widget, 而且还阻塞了我其他任务
也是因为重构时要求在完整正确的代码上改。不然一边改一边加特性还要修问题，在自己不熟悉UI框架的情况下很难正确。

要是这个作者能把他 a = initial; a = op(a, b) | a = initial; if p(a): a = b 的这种坏习惯改一改，学会多建立私有方法/局部函数 就好了，我看充满重赋值的代码时是相当头疼的……

不能怪我抱怨 ，因为这代码真的是让人无法忍受…… 你看这个，只有 anchor 一个变量，他竟然在一个循环里，给这个玩意写了两遍， 而且if体只引用到了self.... 面向对象的优势何在

唉真是头疼呢。要是这些大佬能在写的时候注意点，就不会出现这么多难以复用的代码了