pythonccppprogram手册资源-CSDN文库

5星 · 超过95%的资源需积分: 9 155 浏览量 2017-10-29 17:30:59 上传评论收藏 674KB PDF 举报

标题：“Python C/C++ Program 手册”描述：“Python C/C++ Program 混合编程，基于Python 3.6.3版本” 知识点详细说明： 1. Python与C/C++混合编程的概念和应用范围：混合编程是指将不同编程语言编写的代码集成到一个项目中，以利用各自语言的优势。在Python与C/C++的混合编程中，Python代码提供高级编程的便利和快速开发的特点，而C/C++代码则用于实现对性能要求极高的底层操作。对于需要频繁与硬件交互或者算法效率要求极高的场景，混合编程显得尤为重要。 2. Python扩展模块的添加： Python支持通过C语言添加新的内置模块，这为Python带来了巨大的灵活性。使用C语言编写的模块可以实现Python自身无法直接做到的两种事情：一是实现新的内置对象类型，二是调用C库函数和系统调用。为了支持扩展，Python提供了API（应用程序编程接口），定义了一系列的函数、宏和变量，让开发者可以访问Python运行时系统的大部分功能。 3. 扩展模块的编译与依赖性：扩展模块的编译依赖于其预期用途以及系统环境。开发者需要根据不同的需求和系统设置进行详细配置。需要注意的是，C扩展接口特定于CPython解释器，这意味着扩展模块不能在其他Python实现上使用。这种限制意味着在某些情况下可能需要避免使用C扩展以保持代码的可移植性。 4. 避免使用C扩展的替代方案：尽管使用C编写扩展可以提供更好的性能，但在某些情况下可以避免编写C扩展来保留代码的可移植性。例如，当需要调用C库函数或系统调用时，开发者应该考虑使用ctypes模块或cffi库而不是编写自定义C代码。这些模块允许用Python代码编写以与C代码交互，它们在不同Python解释器实现之间的可移植性要比编写和编译C扩展模块更好。 5. 创建Python扩展模块的实例：文档提供了一个简单的示例，通过创建一个名为spam的扩展模块来调用C库中的system函数。这个模块允许Python代码像调用内置函数一样调用system函数。具体来说，这个模块允许用户在Python中直接执行如"ls -l"这样的系统命令。 6. 扩展模块源文件的创建和命名规则：模块的源文件通常以"spammodule.c"命名，如果模块名称很短。如果模块名称较长，如spammify，则源文件可以命名为"spammify.c"。源文件的第一行通常包含#include"Python.h"来引入Python API，同时可以在文件顶部添加模块作用描述和版权声明。 7. 编译扩展模块需要注意的细节：由于Python可能会定义一些预处理器定义，这些定义可能会影响某些系统上的标准头文件，因此必须在包含任何标准头文件之前先包含Python.h头文件。所有Python.h定义的用户可见符号都有一个前缀Py或PY，这是一个明确的标识。 8. 使用ctypes和cffi模块：这两个模块允许Python代码与C代码进行交互，提供了一种无需编写和编译C扩展模块的方式，从而保持了代码的可移植性。ctypes模块是Python标准库的一部分，允许直接调用C语言库函数，而无需修改底层代码。cffi库则提供了一个更简洁的接口，可以调用C代码，并且更易于与C代码交互。总结，Python C/C++混合编程手册详细介绍了如何通过C或C++扩展Python的功能，包括如何创建扩展模块、模块编译的注意事项以及如何在保持代码可移植性的同时提高性能。文档还提供了具体示例，并讨论了在不需要C扩展的情况下使用的替代模块，这些知识点对于需要深入Python底层的开发者来说是非常有价值的。

资源推荐

资源详情

资源评论

1. Extending Python with C or C++

It is quite easy to add new built-in modules to Python, if you know how to program in C. Such

extension modules can do two things that can’t be done directly in Python: they can

implement new built-in object types, and they can call C library functions and system calls.

To support extensions, the Python API (Application Programmers Interface) defines a set of

functions, macros and variables that provide access to most aspects of the Python run-time

system. The Python API is incorporated in a C source file by including the header "Python.h".

The compilation of an extension module depends on its intended use as well as on your

system setup; details are given in later chapters.

Note: The C extension interface is specific to CPython, and extension modules do not

work on other Python implementations. In many cases, it is possible to avoid writing C

extensions and preserve portability to other implementations. For example, if your use case

is calling C library functions or system calls, you should consider using the ctypes module

or the cffi library rather than writing custom C code. These modules let you write Python

code to interface with C code and are more portable between implementations of Python

than writing and compiling a C extension module.

1.1. A Simple Example

Let’s create an extension module called spam (the favorite food of Monty Python fans…) and

let’s say we want to create a Python interface to the C library function system(). [1] This

function takes a null-terminated character string as argument and returns an integer. We want

this function to be callable from Python as follows:

>>> import spam

>>> status = spam.system("ls -l")

Begin by creating a file spammodule.c. (Historically, if a module is called spam, the C file

containing its implementation is called spammodule.c; if the module name is very long, like

spammify, the module name can be just spammify.c.)

The first line of our file can be:

#include

<Python.h>

which pulls in the Python API (you can add a comment describing the purpose of the module

and a copyright notice if you like).

Note: Since Python may define some pre-processor definitions which affect the standard

headers on some systems, you must include Python.h before any standard headers are

included.

All user-visible symbols defined by Python.h have a prefix of Py or PY, except those defined in

standard header files. For convenience, and since they are used extensively by the Python

interpreter, "Python.h" includes a few standard header files: <stdio.h>, <string.h>,

<errno.h>, and <stdlib.h>. If the latter header file does not exist on your system, it declares

the functions malloc(), free() and realloc() directly.

The next thing we add to our module file is the C function that will be called when the Python

expression spam.system(string) is evaluated (we’ll see shortly how it ends up being called):

static

PyObject *

spam_system(PyObject *self, PyObject *args)

{

const

char *command;

int sts;

(!PyArg_ParseTuple(args, "s", &command))

return

NULL;

sts = system(command);

return

PyLong_FromLong(sts);

}

There is a straightforward translation from the argument list in Python (for example, the single

expression "ls -l") to the arguments passed to the C function. The C function always has

two arguments, conventionally named self and args.

The self argument points to the module object for module-level functions; for a method it

would point to the object instance.

The args argument will be a pointer to a Python tuple object containing the arguments. Each

item of the tuple corresponds to an argument in the call’s argument list. The arguments are

Python objects — in order to do anything with them in our C function we have to convert them

to C values. The function PyArg_ParseTuple() in the Python API checks the argument types

and converts them to C values. It uses a template string to determine the required types of the

arguments as well as the types of the C variables into which to store the converted values.

More about this later.

PyArg_ParseTuple() returns true (nonzero) if all arguments have the right type and its

components have been stored in the variables whose addresses are passed. It returns false

(zero) if an invalid argument list was passed. In the latter case it also raises an appropriate

exception so the calling function can return NULL immediately (as we saw in the example).

1.2. Intermezzo: Errors and Exceptions

An important convention throughout the Python interpreter is the following: when a function

fails, it should set an exception condition and return an error value (usually a NULL pointer).

Exceptions are stored in a static global variable inside the interpreter; if this variable is NULL

no exception has occurred. A second global variable stores the “associated value” of the

exception (the second argument to raise). A third variable contains the stack traceback in

case the error originated in Python code. These three variables are the C equivalents of the

result  in  Python  of  sys.exc_info()  (see  the  section  on  module  sys  in  the  Python  Library
Reference). It is important to know about them to understand how errors are passed around.
The Python API defines a number of functions to set various types of exceptions.
The most common one is PyErr_SetString(). Its arguments are an exception object and a C
string. The exception object is usually a predefined object like  PyExc_ZeroDivisionError. The
C string indicates the cause of the error and is converted to a Python string object and stored
as the “associated value” of the exception.
Another useful function is PyErr_SetFromErrno(), which only takes an exception argument and
constructs the associated value by inspection of the global variable  errno. The most general
function  is  PyErr_SetObject(),  which  takes  two  object  arguments,  the  exception  and  its
associated value. You don’t need to Py_INCREF() the objects passed to any of these functions.
You  can  test  non-destructively  whether  an  exception  has  been  set  with  PyErr_Occurred().
This returns the current exception object, or NULL if no exception has occurred. You normally
don’t need to call PyErr_Occurred() to see whether an error occurred in a function call, since
you should be able to tell from the return value.
When a function f that calls another function g detects that the latter fails, f should itself return
an error value (usually NULL or  -1). It should not call one of the  PyErr_*() functions — one
has already been called by g. f’s caller is then supposed to also return an error indication to its
caller, again without calling PyErr_*(), and so on — the most detailed cause of the error was
already  reported  by  the  function  that  first  detected  it.  Once  the  error  reaches  the  Python
interpreter’s  main  loop,  this  aborts  the  currently  executing  Python  code  and  tries  to  find  an
exception handler specified by the Python programmer.
(There  are  situations  where  a  module  can  actually  give  a  more  detailed  error  message  by
calling  another  PyErr_*()  function,  and  in  such  cases  it  is  fine  to  do  so.  As  a  general  rule,
however, this is not necessary, and can cause information about the cause of the error to be
lost: most operations can fail for a variety of reasons.)
To  ignore  an  exception  set  by  a  function  call  that  failed,  the  exception  condition  must  be
cleared explicitly by calling PyErr_Clear(). The only time C code should call PyErr_Clear() is
if it doesn’t want to  pass the error on to the interpreter but wants to handle it completely by
itself (possibly by trying something else, or pretending nothing went wrong).
Every failing malloc() call must be turned into an exception — the direct caller of malloc() (or
realloc())  must  call  PyErr_NoMemory()  and  return  a  failure  indicator  itself.  All  the  object-
creating  functions  (for  example,  PyLong_FromLong())  already  do  this,  so  this  note  is  only
relevant to those who call malloc() directly.
Also note that, with the important exception of PyArg_ParseTuple() and friends, functions that
return an integer status usually return a positive value or zero for success and  -1 for failure,
like Unix system calls.
Finally,  be  careful  to  clean  up  garbage  (by  making  Py_XDECREF()  or  Py_DECREF()  calls  for
objects you have already created) when you return an error indicator!

The choice of which exception to raise is entirely yours. There are predeclared C objects

corresponding to all built-in Python exceptions, such as PyExc_ZeroDivisionError, which you

can use directly. Of course, you should choose exceptions wisely — don’t use

PyExc_TypeError to mean that a file couldn’t be opened (that should probably be

PyExc_IOError). If something’s wrong with the argument list, the PyArg_ParseTuple() function

usually raises PyExc_TypeError. If you have an argument whose value must be in a particular

range or must satisfy other conditions, PyExc_ValueError is appropriate.

You can also define a new exception that is unique to your module. For this, you usually

declare a static object variable at the beginning of your file:

static

PyObject *SpamError;

and initialize it in your module’s initialization function (PyInit_spam()) with an exception object

(leaving out the error checking for now):

PyMODINIT_FUNC

PyInit_spam(void)

{

PyObject *m;

m = PyModule_Create(&spammodule);

(m == NULL)

return

NULL;

SpamError = PyErr_NewException("spam.error", NULL, NULL);

Py_INCREF(SpamError);

PyModule_AddObject(m, "error", SpamError);

return

}

Note that the Python name for the exception object is spam.error. The PyErr_NewException()

function may create a class with the base class being Exception (unless another class is

passed in instead of NULL), described in Built-in Exceptions.

Note also that the SpamError variable retains a reference to the newly created exception class;

this is intentional! Since the exception could be removed from the module by external code,

an owned reference to the class is needed to ensure that it will not be discarded, causing

SpamError to become a dangling pointer. Should it become a dangling pointer, C code which

raises the exception could cause a core dump or other unintended side effects.

We discuss the use of PyMODINIT_FUNC as a function return type later in this sample.

The spam.error exception can be raised in your extension module using a call to

PyErr_SetString() as shown below:

static

PyObject *

spam_system(PyObject *self, PyObject *args)

{

const

char *command;

int sts;

剩余65页未读，继续阅读

评论收藏

内容反馈

Warg

2017-11-16

c++的调用ptython会不会影响效率

jxusthusiwen

粉丝: 997
资源: 8

python c cpp program 手册

最新资源

python c cpp program 手册

Python.cpp

python相关官方手册

cpp手册(chm)

python手册.doc

python调cpp.zip

Python必备背记手册

python3.10中文使用手册

Python-背记手册

python-3.90 文档 手册 中文版.chm

python program

python language program

Python学习手册

python-program-

python切片理解.cpp

Python win32 手册

python-3.86 文档 手册 中文版.zip

Python+中文手册.pdf_python中文手册_Python中文手册_python_

Python网络爬虫技术手册 源码

python-3.86 文档 手册 中文版.chm

python自动化办公手册.pdf

Python速查手册.pdf

Python库reportLab用户手册+API

Python 编程手册 (CHM),python编程手册 中文pdf,Python源码.zip

Python库参考手册.pdf

Python背记手册 相关资料

python中文参考手册

Python 2.7帮助手册

python中文手册(v2.5pdf,v2.4chm)

最新资源

python-3.90 文档手册中文版.chm

python-3.86 文档手册中文版.zip

Python网络爬虫技术手册源码

python-3.86 文档手册中文版.chm

Python 编程手册 (CHM),python编程手册中文pdf,Python源码.zip

Python背记手册相关资料