在扩展脚本方面，用户为何不太愿意接受 Python ?

大家好，我是Reqable的开发者，给大家分享我在推广 Python 作为程序扩展脚本时遇到的一些问题和思考。如果大家对这个方面有想法和建议也非常欢迎一起讨论，不甚感激。

先说下大体的背景，我的产品 Reqable 是 API 抓包和测试一体化工具。这一类工具基本上都会用到扩展脚本，比如 Fiddler 使用了 FiddlerScript 作为扩展脚本，Postman 和 Proxyman 等使用 Javascript 。用户可以编写扩展脚本来动态地修改请求或者响应数据，相比静态功能来说，提供了更多的可能性。

在设计 Reqable 的时候，我考虑了两种方案：方案 A 是 Javacript ，方案 B 是 Python ，最后定下来方案 B 。谈谈我当初的考虑，Reqable 本身是基于 Flutter 而不是基于 Web 引擎，如果需要支持 Javacript 需要像 React Native 一样额外引入 JSCore 来解释执行 Javacript ，技术实现上来说稍微麻烦点但难度也不大，包体积会大一些但也还好。对于 Python 而言，主流 Windows 和 Mac 上系统默认都已经预安装了，用 Linux 的基本上也会安装，所以可以直接借助用户的 Python 环境来执行脚本，不需要引入额外的库。另外，我考虑到 Python 的在用户宽度可能会更广，比如测试工程师、安全工程师、爬虫工程师等等，而 Javacript 在前端会更加流行。综上原因，最终我选择了 Python 作为扩展脚本语言。

但是想法虽好，用户却不是很买单。有些用户建议我支持 Javacript 脚本，还有一些说 Python 直接劝退。这些反馈让我不得不重新审视之前的想法，考虑是否需要增加 Javascript 作为扩展脚本。当然，维护两套扩展脚本框架我不是很情愿，这个会极大地增加后续维护和迭代的工作量。技术实现难度反而是其次，大佬 Levi 也很贴心地给我提供了他产品目前使用 Javascript 作为扩展脚本的方案： https://zhuanlan.zhihu.com/p/672772729 。

说回目前的困境，大家不太能接受 Python 的原因，我的个人的反思和调研出来的是以下几点：

Python 作为扩展脚本不多见，或者和用户的技术栈不匹配。
Reqable 内置的代码编辑器功能不完善，无法流畅编写 Python 代码。
生态不佳，大家更喜欢现成拿来就用的而不是自己去编写。

针对这几个原因，我做了一些努力和尝试，希望能再挣扎几下：

第一点：技术栈的问题目前无解，但我还是相信 Python 的用户宽度更广。当然，如果能熟用 GPT ，技术栈也不是什么问题，直接提需求让 GPT 写。

第二点：确实是一个很大的问题，例如代码编辑器缺少代码提示和补全，调试功能不方便。针对这个问题，我完善了代码编辑器，加上了代码提示和补全功能。对于调试，则提供了日志控制台功能，当然断点调试目前还不知道怎么去支持。

第三点：对于拿来主义，我的设想是提供一个开源的公共模板仓库，将一些常用的脚本放进去，用户可以直接在 Reqable 里面 Fork 并使用。例如，我写了个利用 Python 扩展脚本自动生成并添加阿里云 OSS 资源访问的签名头部。

我暂时就想到了这么多，效果好不好目前还不确定，如果大家还有想法和见解，欢迎补充。

GeruzoniAnsasu

291 天前

有点无语……

> 主流 Windows 和 Mac 上系统默认都已经预安装了，用 Linux 的基本上也会安装，所以可以直接借助用户的 Python 环境来执行脚本

这个选型初衷就已经走偏了…… 本来作为一个内嵌 DSL, 你该考虑的重点是语言本身好不好写，容不容易把宿主的能力暴露给 DSL 。巧了，python 恰巧就能归到写起来手感很屎的那一类里。

而且 python 最恼人的一点就是 interpreter 的依赖和管理，没有用户会想让系统内置的 python 来对接第三方产品的自动化接口，因为这很可能意味着要往系统 python 库里装一堆平时用不到的依赖，很可能系统升一下级产品不能用了或者产品升一下级突然告知系统里的 runtime 不匹配。python 的多版本虚拟环境解决方案是你能见到的所有现代编程语言里最原始也最冗余的 —— 把一个特定版本的、编译好的、完整的 python 运行时和依赖库复制到工程所在的目录里，这想想都觉得不太高明……

另外 python 和 js 的 sense 完全就不一样。python 从很多年前我们学着用开始，直到今天，都一直被宣称成「胶水语言」 —— 也的确如此，它并不擅长嵌入到其它运行环境里；在使用 python 的场合，python 必须 **作为宿主** 或至少存在一个独立 runtime 「胶合」各层 Application Interface 才比较易用，跟 js 和 lua 这种向宿主中嵌入一种控制器运行时的性质并不一样。

你可以把产品的能力导出成 python 的 FFI ，而且这样也还会有一大批运维/开发者会乐于使用，但这与你需要为你的产品指定一种语言来表达程序化的过程是两回事。

LeeReamond

290 天前

其实你这选型说到最后就两点，只会写 python 的出来吹 python ，然后就是只会写 javascript 的出来吹 javascript 了，仅此而已，后者毕竟是设计者本人不止一次承认存在多处设计缺陷的语言，ES6 后开始逐渐找补，你感觉有问题也是正常的。

优势在于，简单者简单，让简单大行其道，导致想搞个 js 引擎那是再容易不过，现代电脑里没个十个八个 js 引擎都不好意思出来说话。。如果用 Python 那么好处是可以依托庞大生态，问题上面几层也说了，扩展管理和环境隔离，不用质疑，截至目前全网尚无什么理想方案，因为其应用程序绝大多数不以分发形式存在。虽然你可以尝试额外带一个解释器，但想必细节上需要相当多的额外工作。

如果想实现的功能不需要强描述能力，Lua 确实也是可以考虑选项，毕竟是被大量验证的插入方案。

secondwtq

290 天前

这个是你选错了赛道，如果是 VFX 领域的软件，Python 是业界标准，所有主流软件都带一套 Python API ，你不带是你的问题（这个大概是十年前开始的趋势？）。ML 领域同理。相似地，在 EDA 领域，Tcl 是标准； Web 前端领域 JavaScript 是标准； Gamedev 的话 C# 和 Lua 多一些。

所以对于“Python 作为扩展脚本常不常见”的回答，更合适的是“有些地方常见，有些地方不常见”。而正是因为楼主试图用一套解决方案照顾不同群体，那就必然出现这类问题。Python 和 JavaScript 都只能 cover 到一部分人，楼主接收到的反馈可能存在幸存者偏差，也许如果楼主当年用了 JavaScript ，就会有另外一批人出来喊为什么不支持 Python ...

至于后面的两条问题，这个就和用哪个语言无关了，工具和生态是所有项目永远的话题。

我个人的思路：
* 扩展 API 不局限于单一语言。这个有三个具体的例子，第一个是很多 C/C++ 项目不会直接提供脚本语言的 binding ，而是直接暴露 C API ，几乎任何地方都可以用 FFI 调用，对于各个语言的 binding 由社区维护单独的项目；第二个是各种 Web 服务同样是只暴露统一的 Web API ，不下沉到具体语言；第三个是 Web 里的 DOM API ，同样并不以语言特定的形式定义，而是使用一套单独定义的 Web IDL 语言定义，这个稍微好一点，因为能直接映射到 OO 语言。
* 同样地，解决编写体验问题，不局限于传统思路。而是使用可视化编程的方式，这个也是在 VFX 等领域中被广泛推广的。可视化编辑器和传统文本编辑器本来在设计思路上就有根本性的不同，比如可视化编辑器一般天然要求在某一个地方要有一个对所有操作的列表/搜索框，这在传统文本编辑中是不必要的。
当然这套东西摆出来，并不是对楼主的建议，它不一定适合一个具体的实际问题。这只是我对一个理想的扩展系统的构想。

rxmt

290 天前

我主要语言这俩都不是，写 python 和 js 都用来各种地方写个脚本用一下，这俩现在用 gpt 写起来都挺方便。
对比这俩，我的感受是，python 确实通过依赖完成很多功能，看起来更加自由。venv ，单独环境，依赖用户的 py 环境听起来怪怪的。
js ，我有个疑问，http 各种标准默认应该是前端范畴吧，我觉得除了看规范原文，然后就是看 mdn 了。js 用于接口调试抓包这种事情再正常不过了吧。

python 确实可以完成更多的功能，用户自由度也高。但是，如果用户用这个写 python ，如果用户遇到依赖问题很麻烦，包升级也很费劲，包和包之间的版本依赖也是依赖问题的一部分。

本质你做的是一个抓包，代理，接口调试工具，用 python 追求自由度，功能丰富度，我个人觉得没必要。我觉得我这种非前端工程师调试网络接口，学习 js 是必要的，在 mdn 参考 web 规范也都是 js 。另外，在你的软件里跑 python 如果报错，我还得想想是我的 venv 的问题，还是你的软件的问题。

总结，个人的感受是，因为你做的本质是接口工具，抓包工具，如果 python 作为扩展脚本，会感觉很怪，没必要追求自由度。还想重复一下，非 js 工程师在这种情况下学习 js 我觉得是必要的，不难。语言只是一种工具，个人觉得没必要刻意迎合语言使用者