写在前面：

楼主的总结和建议很深入也很有远见，在此表示感谢！

本人并未参与Python in schedule功能的研发设计，仅以普通用户视角和大家一起分享、讨论，难免不足，欢迎斧正。

针对楼主所提问题的解答：

1、关于ARR自定义静态属性

并非bug。在Python in schedule设计之初并没有考虑调用ARR，因为设计该功能的主要目的之一是替代Action+UDQ的功能，并不涉及（或很少涉及）属性场的调用。

另外，Python in schedule支持第三方库的调用，手册中有，相信楼主看到过，不想麻烦的话，可以参直接考论坛帖子“tNavigator-Python应用-盘点新释放的21.1版内嵌了哪些新的第三方库”。

2、关于grid_arithmetic中可修改属性

grid_arithmetic是在有针对属性场调用的需求后添加的功能。

“python语言原生的修改功能”方面确实还不算太完善，不过就像很多前沿技术一样，都会随着需求的变化而不断迭代，以需求为导向可能更普遍。

所以非常希望大家多提具体需求，集思广益，合理的、面向切实需求的、能难倒现有技术的问题才是真正的好问题！

3、关于__init_script__函数

当前__init_script__中仅支持使用一个API - create_graph()，而graph是存在于整个模型运算过程中的，类似于UDQ，所以楼主的理解是对的。

4、关于脚本的全局变量

原因确实如楼主所推测的那样。

其实在Python in schedule功能刚释放不久我即向研发人员反馈过，在找到简易替代方式后，暂时未考虑补上“全局变量”的功能。

当前替代方式主要有两个，Python in schedule中可自主控制的__init_script__函数以及时间、脚本执行次数等，即可以依据上面两个内容作为判断依据（类似全局变量），自主设计，供参考。

5、tnav的API是不能出现在自定义模块中的

楼主描述的现象确实存在，我当前也不能确定原因。

6、关于Graph值计算的问题

楼主描述的现象其实可以通过“先给变量赋值，然后使用表达式”来解决。

7、关于部署发布的问题

很好的建议，我们会反馈给开发人员。

8、未来展望

感谢楼主的建议与期待！我个人也非常期待tNavigator中能够包含一个（多个）高开放度的插件系统，能够深度满足各类需求。