在另一个python版本中导入cython生成的* .so-module [英] Importing cython generated *.so-module in another python-version

查看:121
本文介绍了在另一个python版本中导入cython生成的* .so-module的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

应如何在python中导入文件 myModule.cpython-35m-x86_64-linux-gnu.so ?有可能吗?

我尝试了常规方法:

  import myModule 

口译员说:

 `ModuleNotFoundError:没有名为"myModule"的模块 

这是我无法在正在使用的集群中安装的软件,因此我仅提取了 .deb 程序包,并且没有要安装的wheel文件或结构./p>

解决方案

在另一个Python版本中使用为一个Python版本构建的C扩展名是有问题的.通常(至少对于Python3),有一种机制可以区分不同Python版本的C扩展名,因此它们可以共存于同一目录中.

在您的示例中,后缀为 cpython-35m-x86_64-linux-gnu ,因此,此C扩展名将由x86_64 Linux上的CPython3.5拾取.如果您尝试使用另一个Python版本或另一个平台导入此扩展,则该模块不可见,并引发 ModuleNotFoundError .

可以看到当前Python版本接受哪些后缀,例如通过:

 >>>导入_imp>>> _imp.extension_suffixes()['.cpython-36m-x86_64-linux-gnu.so','.so'] 

即使是一个聪明的人,并将扩展名重命名为简单的 .so ,因此它也可以被Finder取用-这可以/确实适用于某些Python版本的某些组合平台进行扩展-但是这种方法无法长期持续,是正确的选择.

正确的做法是使用正确的Python版本/来构建C扩展名/以使用正确的轮子.


通常,为python版本(例如PythonA.B)构建的C扩展不能被其他Python版本(例如PythonC.D)使用,因为这些扩展/模块是针对特殊的Python-库和所需的功能可能不再存在/尚​​未出现在另一个版本的库中.

这不同于 *.py 文件,并且更类似于 *.pyc 文件,不能与其他版本一起使用.

PEP-3147 规定了 *的满足条件.pyc -files, PEP-3149 的作用相同对于C扩展名. PEP-3149 并不是最新的技术,作为仅修正在Python3.5 中,可以在此处中找到整个讨论./p>

How should a file myModule.cpython-35m-x86_64-linux-gnu.so be imported in python? Is it possible?

I tried the regular way:

import myModule

and the interpreter says:

`ModuleNotFoundError: No module named 'myModule'`

This is a software that I can't install in the cluster that I am working at so I just extracted the .deb package and it does not have a wheel file or structure to install.

解决方案

It is problematic to use a C-extension built for one Python version in another Python version. Normally (at least for Python3) there is a mechanism in place to differentiate C-extensions for different Python versions, so they can co-exist in the same directory.

In your example, the suffix is cpython-35m-x86_64-linux-gnu so this C-extension will be picked up by a CPython3.5 on a x86_64 Linux. If you try to import this extension with another Python-version or on another plattform, the module isn't visible and ModuleNotFoundError is raised.

It is possible to see, which suffixes are accepted by the current Python version, e.g. via:

>>> import _imp
>>>_imp.extension_suffixes()
['.cpython-36m-x86_64-linux-gnu.so', '.so']

Even if one might want to be clever and rename the extension to simple .so, so it can be picked up by the Finder - this can/does work for some Python-version combinations on some platforms for some extension - yet this approach cannot be sustained in the long run and is not the right thing to do.

The right thing is to build the C-extension for/with the right Python-version/to use the right wheel.


In general, a C-extension built for a python-version (let's say PythonA.B) cannot be used by another Python version (let's say PythonC.D), because those extensions/modules are linked against a special Python-library and the needed functionality might no longer/not yet be present in the library of another version.

This different to *.py-files and more similar to *.pyc-files which cannot be used with a different version.

While PEP-3147 regulates the suffices of *.pyc-files, PEP-3149 does the same for the C-extensions. PEP-3149 is however not the state-of-the-art, as some of the problems where fixed only in Python3.5, the whole discussion can be found here.

这篇关于在另一个python版本中导入cython生成的* .so-module的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆