能运行 Python 示例，为什么不等于实现了完整 Python？
小体积解释器展示了受限目标下的设计取舍。评估这类项目，应分别检查能解析的语法、执行结果和输入边界，不能只凭一段示例运行成功判断兼容性。
更新于
先把展示目标与兼容目标分开
据 OSCHINA 对 Henley 编程挑战的报道，这个项目以极小体积实现解释器，并对可接受的输入作出了限制。理解它时，值得先区分两种问题：指定示例能否运行，以及任意符合语言规范的程序能否运行。前者验证一个具体任务，后者需要远大得多的验证范围。展示程序成功是有效证据，但证据所覆盖的范围应停留在已经检查的输入上，不能直接延伸到所有程序。
语法看起来相同，执行行为仍要核对
作为阅读这类项目的一种方法，可以把检查拆成输入识别和执行结果两个层次。代码里出现熟悉的循环或函数写法，只能说明需要继续检查这些结构如何被处理；它本身不能证明执行规则完整一致。建议选取一个已经声明支持的功能，用最小示例记录预期输出，再观察实际输出。若要增加新的写法，应先确认它是否属于项目承诺支持的范围，避免把范围外的输入误当成已承诺功能的缺陷。
边界测试比重复跑同一示例更有信息量
报道提到，该解释器没有错误处理。这个限制提醒读者，成功路径和异常输入是两类不同的检查。作为测试建议，可以先保存能正常运行的基准示例，然后每次只改变一个条件，并记录输入、输出或失败表现。这样容易分辨究竟是哪项变化影响了结果。异常输入的表现不能靠猜测补齐，也不应因为演示没有触发错误，就推断工具已经具备清楚的报错和恢复能力。
评价紧凑设计时，应写清楚结论的适用范围
这种挑战的阅读价值可以落在设计取舍上，而不必转化为通用工具选型结论。建议把观察结果写成有边界的描述，例如某个已支持示例在特定环境下得到预期输出，并附上实际测试条件；没有亲自运行时，则只说明报道展示了什么。若准备将项目用于教学演示或进一步实验，还应另行检查运行条件和使用限制。体积小与兼容范围大是不同指标，单靠其中一个指标不能替另一个作出保证。
资料与延伸阅读
你可以通过以下原始资料核对文中概念，并继续深入阅读。