It returns either a fully-initialized module, or a$_{PyModuleDef}$instance. See initializing-modules for details. 

For modules with ASCII-only names, the function must be named PyInit_<modulename> , with <modulename> replaced by the name of the module. When using multi-phase-initialization, non-ASCII mod- ule 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 PEP 489 for details. 

## 2.4.1 Building C and C++ Extensions with distutils 

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,$_{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$_{setup.py}$ , and a file$_{demo.c}$ , running 

python setup.py build 

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

In the$_{setup.py}$ , all execution is performed by calling the$_{setup}$function. This takes a variable number of key- word 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 mod- ules, like Python source modules, documentation, subpackages, etc. Please refer to the distutils documentation in 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$_{setup()}$ , to better structure the driver script. In the example above, the ext_modules argument to setup() is a list of extension modules, each of which is an instance of the Extension . In the example, the instance defines an extension named$_{demo}$ which is build by compiling a single source 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', 

(continues on next page) 

