Nyakku Shigure

> 其余暂时没什么大问题，等 CI 跑完我看下效果～ 其实之前就发现一个体验比较差的问题就是，log 太多了，包括示例代码检查，对于大多数工具来说，默认行为是如果 success，那么是静默的，不会在成功的那些 case 上打印过多 log（除非开 `--verbose`），只有 fail 才会打印详细日志，对于这一点来说我们的日志对于用户是不友好的，之前示例代码还好些吧，加上类型检查就不太可读了，这个可以之后专门优化一下（体验优化，单独 PR） > 这个任务可以放到 `代码标注` 完成之后 诶？会不会有点晚？按我理解这个功能可以用来摸底和统计 API 支持情况，感觉可以在批量任务的同时做？ > 这个 type checking 比之前的示例代码那个任务还麻烦 ～ 其中应该会有一些依赖关系，在没有完成基础标注的情况下，type checking 可能出问题...

> 那么，去掉 debug？ 嗯，可以之后试一下 > 另外，关于全量 docstring 和黑白名单的问题，昨晚想了想，能不能这样： 嗯嗯，不过之后是否有一些情况确实需要禁用掉呢？就像我上面说的「因为大概率，我们总有一些就是需要禁掉的」，是否有方式灵活禁用某些 case 呢？（比如 cpplint 的 `// NOLINT`、ruff 的 `# noqa`） > `[typing_checking]` 喔喔才发现上面写错了 :joy:，应该是 `[type_checking]`，`typing_checking` 怪怪的

> 用 # type: ignore ？比如： 喔喔，局部的这种，可以的，这里说的是整个 case 的情形，如果不至于写太多 `type: ignore` 的话就没问题 另外可以考虑下示例代码展示时是否要将 `type: ignore` 删掉～

> 如果没有 `docstring` 的需要，那么 `paddle.base.core.DataType` 的 stub file 也不需要 ～ 这个我没有太理解，stub file 更主要提供的是类型信息，docstring 则是次要的，为什么没有 docstring 的需要就可以不用 stub file 了呢？ 其实根据 typeshed 的规范[^1]，stub file 不应该写 docstring 的，当然，这个在社区里也有争议，但这里以是否有 docstring 来评判是否加 stub file...

> pybind 的接口如果用了 stub，好像必须得把 docstring 加进去，不然 vscode 我试了，貌似 docstring 的提示就没了? 这是没问题的，因为 pybind API 的 docstring 是运行时才能获取的，VS Code（pylance）当然拿不到 我只是用来佐证「但这里以是否有 docstring 来评判是否加 stub file 我觉得是颠倒主次关系的」哈，没说我们不加，而且我们也会「优先」加 type annotation 而不是 docstring，这是这个任务 title 决定的 >...

已确认 `py_func`（PyFuncOp） 不可删除，动转静 TensorHook 依赖该 OP，需要迁移到 PIR

如果能确定不影响 TensorHook 功能，可以删除

## 其它 | 序号 | 认领人 | 文件 | 错误类型 | case | 问题 | 报错 | pr | |:-----:|:--:|:--------------------------------:|:-------:|:--------------------------------:|:------------:|:--:|:--:| | 🟡32 | | test_op_attr.py | 量化 | `CheckOpAttr.test_set_op_attrs` |...

> 要实现这个感觉是不合适的。以你提到的柯南为例，在 b 站的设计下中配和日配，相当于是两个不同的番剧。 确实 如果说有一种办法能够找到不同配音下的关联关系，以及能够确保两个视频流是一致的，我觉得是可以考虑实现的，只不过目前来看应该是不太容易的 不过关于多音轨我之前发现一个可能比较适合用于实验的番剧：[《暂停！让我查攻略》](https://www.bilibili.com/bangumi/play/ep479211)，这部番剧是存在多配音机制的（APP 端），但因为 Web 端没有实现这个机制我不太清楚是不是只有 APP 端 API 才能获取其他配音的音频流，如果有办法直接通过 Web 端 API 获取到其他配音音频流的话，我觉得这个番剧可以尝试多音轨的功能～当然如果 Web 端没有这个 API 就算啦～

没有，如有需要可以提 PR