python不同模块间传递数据_Python：在一个项目中使用支持不同Python版本的模块

确实没有好办法避免这种解决方法.

从概念上讲,没有理由不能将两个解释器嵌入到同一个过程中.但实际上,CPython解释器依赖于某些静态/全局状态.虽然3.7比那更好,比如3.0或2.6,但是这个状态仍然没有被消除.1而且,C链接的工作方式,没有办法解决这个问题而不改变解释器.

此外,嵌入CPython并不难,但这并不是一件容易的事,因为将解释器作为子进程运行是微不足道的 – 并且它可能比提出一种在子进程之间传递或共享状态的有效方法更难.

当然除了CPython之外还有其他的解释器.但是2.7和3.x版本的其他主要实现都不容易嵌入(PyPy),而且易于嵌入的两个版本没有3.x版本,也只能嵌入到另一个VM中,并且可以不要运行C扩展模块(Jython和IronPython).可以做一些事情,比如使用JEP在JVM中通过JNI嵌入CPython 3.7,同时在同一个JVM中本地使用Jython 2.7,但我怀疑这种方法对你有用.

同时,我提到在进程之间传递或共享数据通常并不难.

>如果您没有那么多数据,通常可以通过管道腌制它.

>如果你确实拥有大量数据,它通常或者可能存储在内存中的某些结构化形式的numpy数组,大量的ASCII或UTF-8文本,ctypes结构数组等等 – 你可以覆盖在mmap或共享内存段上.

>或者,当然,您可以提出自己的协议并通过(UNIX或IP)套接字与其进行通信.但是你不一定要跳到那个选项.

请注意,多处理支持前两个 – 虽然要利用独立的解释器来利用它,但你必须深入研究它的来源并提取你需要的位.还有第三方库可以提供帮助. (例如,如果你需要腌制本身不发泡的东西,答案通常就像“用莳萝替代泡菜”一样简单.)

1.以各种受限制的方式运行多个子解释器确实可以处理mod_wsgi之类的事情,而PEP 554旨在让事情处于一个状态,您可以在同一个过程中轻松,干净地运行多个3.7子解释器,但仍然完全没有像完全独立的嵌入式CPython-子解释器共享一个GIL,一个循环收集器,一个atexit处理程序等.