开源 企业版 高校版 私有云 模力方舟 AI 队友
代码拉取完成,页面将自动刷新
捐赠
捐赠前请先登录
扫描微信二维码支付
取消
支付完成
支付提示
将跳转至支付宝完成支付
确定
取消
1 Star 0 Fork 0

source-code-analysis/python3.7.4

加入 Gitee
与超过 1400万 开发者一起发现、参与优秀开源项目,私有仓库也完全免费 :)
免费加入
已有帐号? 立即登录
文件
master
分支 (1)
master
master
分支 (1)
master
克隆/下载
克隆/下载
提示
下载代码请复制以下命令到终端执行
为确保你提交的代码身份被 Gitee 正确识别,请执行以下命令完成配置
初次使用 SSH 协议进行代码克隆、推送等操作时,需按下述提示完成 SSH 配置
1 生成 RSA 密钥
2 获取 RSA 公钥内容,并配置到 SSH公钥
在 Gitee 上使用 SVN,请访问 使用指南
使用 HTTPS 协议时,命令行会出现如下账号密码验证步骤。基于安全考虑,Gitee 建议 配置并使用私人令牌 替代登录密码进行克隆、推送等操作
Username for 'https://gitee.com': userName
Password for 'https://userName@gitee.com': # 私人令牌
master
分支 (1)
master
python3.7.4
/
Doc
/
extending
/
building.rst
python3.7.4
/
Doc
/
extending
/
building.rst
building.rst 6.47 KB
一键复制 编辑 原始数据 按行查看 历史
zhangweibo 提交于 2021年11月17日 13:49 +08:00 . git init
.. highlightlang:: c

Building C and C++ Extensions

A C extension for CPython is a shared library (e.g. a .so file on Linux, .pyd on Windows), which exports an initialization function.

To be importable, the shared library must be available on :envvar:`PYTHONPATH`, and must be named after the module name, with an appropriate extension. When using distutils, the correct filename is generated automatically.

The initialization function has the signature:

.. c:function:: PyObject* PyInit_modulename(void)

It returns either a fully-initialized module, or a :c:type:`PyModuleDef` instance. See :ref:`initializing-modules` for details.

.. highlightlang:: python

For modules with ASCII-only names, the function must be named PyInit_<modulename>, with <modulename> replaced by the name of the module. When using :ref:`multi-phase-initialization`, non-ASCII module names are allowed. In this case, the initialization function name is PyInitU_<modulename>, with <modulename> encoded using Python's punycode encoding with hyphens replaced by underscores. In Python:

def initfunc_name(name):
 try:
 suffix = b'_' + name.encode('ascii')
 except UnicodeEncodeError:
 suffix = b'U_' + name.encode('punycode').replace(b'-', b'_')
 return b'PyInit' + suffix

It is possible to export multiple modules from a single shared library by defining multiple initialization functions. However, importing them requires using symbolic links or a custom importer, because by default only the function corresponding to the filename is found. See the "Multiple modules in one library" section in Building C and C++ Extensions with distutils

.. sectionauthor:: Martin v. Löwis <martin@v.loewis.de>

Extension modules can be built using distutils, which is included in Python. Since distutils also supports creation of binary packages, users don't necessarily need a compiler and distutils to install the extension.

A distutils package contains a driver script, :file:`setup.py`. This is a plain Python file, which, in the most simple case, could look like this:

from distutils.core import setup, Extension

module1 = Extension('demo',
 sources = ['demo.c'])

setup (name = 'PackageName',
 version = '1.0',
 description = 'This is a demo package',
 ext_modules = [module1])

With this :file:`setup.py`, and a file :file:`demo.c`, running

python setup.py build

will compile :file:`demo.c`, and produce an extension module named demo in the :file:`build` directory. Depending on the system, the module file will end up in a subdirectory :file:`build/lib.system`, and may have a name like :file:`demo.so` or :file:`demo.pyd`.

In the :file:`setup.py`, all execution is performed by calling the setup function. This takes a variable number of keyword arguments, of which the example above uses only a subset. Specifically, the example specifies meta-information to build packages, and it specifies the contents of the package. Normally, a package will contain additional modules, like Python source modules, documentation, subpackages, etc. Please refer to the distutils documentation in :ref:`distutils-index` to learn more about the features of distutils; this section explains building extension modules only.

It is common to pre-compute arguments to :func:`setup`, to better structure the driver script. In the example above, the ext_modules argument to :func:`~distutils.core.setup` is a list of extension modules, each of which is an instance of the :class:`~distutils.extension.Extension`. In the example, the instance defines an extension named demo which is build by compiling a single source file, :file:`demo.c`.

In many cases, building an extension is more complex, since additional preprocessor defines and libraries may be needed. This is demonstrated in the example below.

from distutils.core import setup, Extension

module1 = Extension('demo',
 define_macros = [('MAJOR_VERSION', '1'),
 ('MINOR_VERSION', '0')],
 include_dirs = ['/usr/local/include'],
 libraries = ['tcl83'],
 library_dirs = ['/usr/local/lib'],
 sources = ['demo.c'])

setup (name = 'PackageName',
 version = '1.0',
 description = 'This is a demo package',
 author = 'Martin v. Loewis',
 author_email = 'martin@v.loewis.de',
 url = 'https://docs.python.org/extending/building',
 long_description = '''
This is really just a demo package.
''',
 ext_modules = [module1])

In this example, :func:`~distutils.core.setup` is called with additional meta-information, which is recommended when distribution packages have to be built. For the extension itself, it specifies preprocessor defines, include directories, library directories, and libraries. Depending on the compiler, distutils passes this information in different ways to the compiler. For example, on Unix, this may result in the compilation commands

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DMAJOR_VERSION=1 -DMINOR_VERSION=0 -I/usr/local/include -I/usr/local/include/python2.2 -c demo.c -o build/temp.linux-i686-2.2/demo.o

gcc -shared build/temp.linux-i686-2.2/demo.o -L/usr/local/lib -ltcl83 -o build/lib.linux-i686-2.2/demo.so

These lines are for demonstration purposes only; distutils users should trust that distutils gets the invocations right.

Distributing your extension modules

When an extension has been successfully build, there are three ways to use it.

End-users will typically want to install the module, they do so by running

python setup.py install

Module maintainers should produce source packages; to do so, they run

python setup.py sdist

In some cases, additional files need to be included in a source distribution; this is done through a :file:`MANIFEST.in` file; see :ref:`manifest` for details.

If the source distribution has been build successfully, maintainers can also create binary distributions. Depending on the platform, one of the following commands can be used to do so.

python setup.py bdist_wininst
python setup.py bdist_rpm
python setup.py bdist_dumb
Loading...
举报
举报成功
我们将于2个工作日内通过站内信反馈结果给你!
请认真填写举报原因,尽可能描述详细。
请选择举报类型
取消
发送
误判申诉

此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。

如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。

取消
提交

简介

暂无描述
取消

发行版

暂无发行版

贡献者

全部

近期动态

不能加载更多了
编辑仓库简介
简介内容
主页
马建仓 AI 助手
尝试更多
代码解读
代码找茬
代码优化
1
https://gitee.com/python_sourcecode/python3.7.4.git
git@gitee.com:python_sourcecode/python3.7.4.git
python_sourcecode
python3.7.4
python3.7.4
master
点此查找更多帮助

搜索帮助

评论
仓库举报
回到顶部
登录提示
该操作需登录 Gitee 帐号,请先登录后再操作。
立即登录
没有帐号,去注册

AltStyle によって変換されたページ (->オリジナル) /