【Hackathon No.89】 Remove circle import Part3

[Liyulingyue]

PR types

Others

PR changes

Others

Describe

• 【PaddlePaddle Hackathon 4】核心框架开源贡献其他任务合集 #50663 (comment)

Details

• 核心框架开源贡献赛道——其他 #50711
• 【Hackathon Hackathon No.89】清理动态 import语句，解决circle import 问题 community#409
• 【Hackathon No.89】 Remove circle import Part2 #51199 此pr未处理utils引入static_analyse的问题，本pr通过拆解文件解除循环import

[paddle-bot]

你的PR提交成功，感谢你对开源项目的贡献!
请关注后续CI自动化测试结果，详情请参考Paddle-CI手册。
Your PR has been submitted. Thanks for your contribution!
Please wait for the result of CI firstly. See Paddle CI Manual for details.

[Liyulingyue]

@Aurelius84 麻烦review后回复一下以下问题：

1. 文件拆分后，命名是否合适
2. 拆分后保持外部从utils调用信息，utils import拆分出去的信息，这样是否合适？

[Aurelius84]

此PR是为了解决 import StaticAnalysisVisitor 和 NodeVarType 的动态import问题么？

[Aurelius84]

@Aurelius84 麻烦review后回复一下以下问题：

1. 文件拆分后，命名是否合适
2. 拆分后保持外部从utils调用信息，utils import拆分出去的信息，这样是否合适？

非常感谢提供的解决方案，拆分文件是一个很通用的思路。这里我想再抛出一个小问题：目前看是因为StaticAnalysisVisitor的导入引入了循环依赖，当前PR是可以解决此问题的。但是否会存在后续再import其他模块也会引入循环依赖的问题。

从Python的包管理机制来看，一般采用“分层”管理的思想，即将通用的、高内聚的工具类函数放到「下层」，框架相关函数放到「中层」、业务相关逻辑放到「上层」。这样平级别可以互相import、父级别可以import子级别函数，但不建议子级别去import父级别的函数，后者一般是导致循环import的主要原因。

所以，欢迎从上面角度思考下utils类函数是否可以按照上述原则拆分给框架中上层来用，可以一起讨论。

[Liyulingyue]

@Aurelius84 麻烦review后回复一下以下问题：

1. 文件拆分后，命名是否合适
2. 拆分后保持外部从utils调用信息，utils import拆分出去的信息，这样是否合适？

非常感谢提供的解决方案，拆分文件是一个很通用的思路。这里我想再抛出一个小问题：目前看是因为StaticAnalysisVisitor的导入引入了循环依赖，当前PR是可以解决此问题的。但是否会存在后续再import其他模块也会引入循环依赖的问题。

从Python的包管理机制来看，一般采用“分层”管理的思想，即将通用的、高内聚的工具类函数放到「下层」，框架相关函数放到「中层」、业务相关逻辑放到「上层」。这样平级别可以互相import、父级别可以import子级别函数，但不建议子级别去import父级别的函数，后者一般是导致循环import的主要原因。

所以，欢迎从上面角度思考下utils类函数是否可以按照上述原则拆分给框架中上层来用，可以一起讨论。

感谢回复。

首先，关于“是否会存在后续再import其他模块也会引入循环依赖的问题”，这主要取决于后续的开发内容，以及对应的开发者的行为，我其实很难预见性地进行一些操作。

其次，关于jit中的uitls类函数。这些函数本质来说是应当被抽取出来放到底层中的。以#51199 为例，is_builtin被迁移到了utils中以避免循环依赖。除此之外，大量的常量字符串声明也被挪动到了utils文件中。但这同样会导致utils中的函数非常杂乱，不具有整体性。因此如果想要对jit内的代码进行重构，不仅仅是函数的重构，可能还需要考虑到按功能类别构造不同的utils文件。

最后，jit内的操作并不是完全孤立的，除了我的一系列pr解决的循环依赖问题之外。还有一些与nn. fluid.等相关的循环依赖没有解决。对于文件的分层重构工作应该也会受到这些文件的解耦影响。

总体来说，我认为应当优先完成circle import的解耦工作，然后在解耦工作的基础上，进一步抽取utils类函数。并且我建议jit中的所有常量字符串定义统一挪动到一个utils文件中，对于其他utils类函数，应当尽可能分类放置。

[Aurelius84]

LGTM