这几天在用木兰语言继续改写
Python 文字冒险游戏例程
时，又体验到引用模块时使用的包路径与 Python 的差别，之前虽然写过相关测试但未整理成文档，在此小结一下。
以下面的文件目录为例（注意：不需在包目录中添加
__init__.py
之类的文件）：
甲和乙为木兰源码，内容如下，
甲.ul
：
a = 3
乙.ul
中引用甲模块：
using 甲
print(甲.a)
如果在“二级包”目录下运行：
$ 木兰 乙.ul
输出 3 无误。
但如果在“二级包”的上一级目录“一级包”下运行则会报错：
$ 木兰 二级包/乙.ul
😰 没找到模块：‘甲’
调用层级如下
见第1行：using 甲
需要将
乙.ul
中的包路径改为才能正确运行：
using 二级包.甲
print(二级包.甲.a)
此时如果有另一个二级包：
也可以在乙中引用丙：
using 二级包2.丙
print(二级包2.丙.b)
丙.ul
内容：
b = 4
在“一级包”下运行
$ 木兰 二级包/乙.ul
输出 4
类似的，如果在“二级包”下运行则会报错：
$ 木兰 乙.ul
😰 没找到模块：‘二级包2’
调用层级如下
见第1行：using 二级包2.丙
简言之，现在看来的包路径规则是：
当前运行目录 + 包路径（将.替换为/）= 模块路径
比如上面在“一级包”下运行时，运行目录为：一级包
引用的模块“甲”的路径为：一级包/二级包/甲
那么包路径就要：二级包/甲（代码中是
using 二级包.甲
）
这样的包路径设定规则比较直观，但也意味着，对于存在引用的模块，必须在一个特定目录下运行，在任何其他目录下运行都会出现无法找到模块的错误。
下面是 0.0.15.1 版重现的几个小功能：
throw 语法，对应 Python 的 raise
isa 内置函数，对应 Python 的 isinstance
改进部分报错信息
文档方面，为便于有意者参与木兰项目的开发维护，编写了
开发流程与项目结构简介
，今后逐步完善。另开始小结
与 Python 的语法对比
。
附：代码量统计
主要部分的代码行数统计，格式为：上次->现在。
木兰代码量 3260 -> 3307
运行环境，实现与测试大部为木兰代码：582
木兰测试用例，包括部分实用小程序（如井字棋）：2678 -> 2725 (报错信息测试用例替代了源码中的注释)
测试/期望值表.py
（从“
运行所有.py
”中提取）：131 -> 133
功用/规律.py
，正则表达式 API 原型：100
分析器/语法成分.py
，从语法分析器中提取出来的枚举常量：82 -> 83
功用/反馈信息.py
：71 -> 75
测试/运行所有.py
，检验所有木兰测试代码片段：62 -> 71
交互.py
，交互环境（REPL）：148
中.py
，主程序：74
功用/调试辅助.py
，：57
setup.py
, 34
测试/unittest/语法树.py
，确保生成的语法树与原始版本一致：88
测试/unittest/正则.py
：62
测试/unittest/交互.py
，交互环境相关测试：28
测试/unittest/所有用例.py
：24
分析器/错误.py
：26
本站新闻禁止未经授权转载，违者依法追究相关法律责任。授权请联系：
oscbianji#oschina.cn
本文标题：
木兰语言 0.0.15.1：继续改写 Python 冒险游戏；引用包路径规则小结
本文地址：
https://www.oschina.net/news/123515
资讯来源：
https://zhuanlan.zhihu.com/p/337101227
专门登录写个评论，为了信创而信创没有任何意义。 如果开源的spring被认为是非自主可控不安全的，那请问Linux和Java属于自主可控吗？那些大数据和人工智能的组件属于自助可控吗？Docker和K8s属于自主可控吗？ 真要完全安全自主的话，国内的计算机行业应该从汇编开始发展。 师夷长技以制夷，我支持自主研发、自主可控的信创策略，但应该是更底层的芯片、操作系统、虚拟机、容器化这些基础组件的研发。像中间件、应用框架这些东西，就算一夜之间所有github的代码全部消失了，集合几家大厂的能力，开发出来又能花多少时间呢？况且现在大厂本身就有很多自研的中间件和框架。 本身东西就不复杂，现在spring、redis这些东西流行只是因为它们诞生的早生态好罢了，而不是难度。为此单独再搞一套轮子我觉得大可不必。
本人原创作者，在此解释声明一二： 1. 我的父母还没有无耻到做这种无耻的事情，我也对我的能力有信心，目前也不需要这些偷鸡摸狗的见不得光的东西来造假，请各位不要以小人之心度君子之腹。 2. 我今年初三，项目是从初一开始做的，各位不相信的欢迎上github看提交记录，可以看一下初版和现在的区别，UI和js都有不小更改。 3. 团队组成：今年一位初三，一位初一，一位5+4制的初一。更新记录中明确记录了哪些功能是哪位所开发的。 4. 我在github上，bilibili上没有受到过任何一个人的质疑，我对中国的网络环境表示蔑视。 5. 本项目的初中只是为了兴趣，没有想到火了起来。 我不理解你们是如何通过代码读出作者年龄的？难道是语文考试要加入代码阅读赏析的题目了吗？真心觉得很厉害。 6. 不愿与某些人同流，也无众位深厚阅历经验，只望能得清白之名。感谢大家让我懂得了何乃人情世故，孰谓世态炎凉，世俗红尘。你们给我的人生上了重要的一课。人间哪有什么真善美啊，呵。社会的病胎罢了。
看了 wangEditor 的公告，如鲠在喉。去年七月，我在一篇《关于剔除 layedit 组件》的公告中，还推荐了几款 editor 组件用于替代，其中就包括了 wangEditor, 转眼之间，仿若时空交错，不免有些感慨。 在国内由个人发起的开源项目，似乎都很难跳出相同的宿命，不断有人走进这个赛道，但能抵达终点并完成突破的却屈指可数。Layui 曾经同样倒在了赛道，2021 年宣布关站之前，Layui 的百度指数还一度领先 Bootstrap, 如此一个拥有广泛用户群体的 UI 库，本该迎来新的突破，却在疾跑中戛然止步，至今令人迷惑。人们看到的，是一篇充满悲情色彩的公告，而公告的背后，是创作者在面对内外交织的困境中不得已做出的举措，当我们没有足够的力量冲破眼前的障碍，除了停下来避开它，还有别的更优选择么。你很难想象除此之外还有多少历史包袱… 譬如，也是由于种种原因，当初 Layui 在 Github 和 Gitee 待处理的 Issue 数量，不下于 2000，各种议题参次不齐，我差不多花了半年时间去逐一审阅，多少个日夜消耗，多少次自我情绪的对抗… 就不多提了。 尽管这两年来，Layui 的受众者已呈断崖式流失，但正因为小众，反而如释重负，甚至让我重新找回了一些开源的纯粹。 共勉 🙂
