首先使用 Python 的原因之一是快速编辑刷新周期，无需交错构建步骤。目前protobuf的实现方式打破了Python语言的这一优势。 Python 有一个非常强大的可以扩展的模块导入系统（参见importlib）。
因此，我想请求对 Python 实现进行更改，以便可以导入存在相应.proto 文件但不存在此类 *.py 文件的 _pb2 模块，并使用 protobuf 实现在运行时动态生成 Python 类在导入库中（当然，智能地缓存它，以便该策略在生产环境中仍然可行且高效）。
注意：这是gRPC 中类似功能请求的依赖项。 （此外，正因为如此，这样的运行时生成机制还需要支持 gRPC 等系统的某种插件机制，以扩展生成的 Python 代码）。
为了获得灵感，该视频讨论了此类实施中涉及的一些内容。
您能否通过在 Python 程序顶部放置一个简短的 bash/其他 shell 脚本来重新编译（天真地）您需要构建的所有 *.proto 文件或（智能地）跟踪 md5 或类似的文件来解决这个问题.proto 文件以查看自上次构建以来哪些已更改？如果这是您的用例，不确定这是否比重建许多小 .proto 文件花费更多或更少的时间。
在可以重新编译的情况下，该解决方案可能会起作用；但是，类似的解决方案在 App Engine 标准环境中不起作用。理想情况下，这将是一个纯 Python 解决方案。
旁注：作为一个 20% 的项目，我开始为此做一些工作//depot/google3/experimental/users/michaelsafyan/proton
然而，我认为这样的东西确实需要由核心 protobuf 团队驱动和支持才能成为现实。
有趣的是，您无法使用 Python 运行时写入文件系统；我之前没有读过有关 App Engine 上的 Python 的内容。感谢您提供的知识：）
与其说你不能编写文件系统，不如说你不能在GAE沙箱中执行protobuf编译器（用C++编写）。
动态生成 _pb2.py 文件将需要协议编译器的 python 实现。维护开销太大了...除非有某种神奇的方法将我们现有的 C++ 编译器代码转换为纯 Python...
嗯...如果从 *.proto 到编译的二进制描述符的转换步骤是一个“服务”，其中标准实现作为协议编译器之上的一层在本地运行，代码在 GAE 标准环境中运行调用相反，服务的托管实现？那行得通吗？ （不过，这需要有人——protobuf 团队或 GAE 中的人——维护服务的托管版本）。
借鉴 Tensorflow Serving 的理念，是否有一种方法可以将您的 .proto 文件托管在 GAE 之外的一个非常适度的服务器上，以保持最新版本的 .proto 已编译并可供使用（可能通过存储 *_pb2.py文件访问速度更快）？我知道这将带来一整套需要考虑的新网络挑战。编辑：而不是让 GAE 或 protobuf 团队来解决托管它的问题，这可能需要比您想要的开发时间更长的时间:)
仅供参考，我有一些处于部分状态的东西（可以与常规Python原型一起使用，但还不能与gRPC一起使用，可以在本地进行编译protoc，但尚未使用网络）。它目前位于我个人帐户下的云源存储库中（一直在 Google 之外开发）...获得将其复制到 Google 下的 GitHub 上的公共存储库的许可的正确方法是什么？
@anandolee 我已经授予您存储库读者对质子的访问权限，它有一个概念验证，您可以将其用作起点（如果您还没有这样的东西）。