SIP - A Tool for Generating Python Bindings for C and C++ LibrariesReference Guide
1 IntroductionThis is the reference guide for SIP 4.7.9. SIP is a tool for automatically generating Python bindings for C and C++ libraries. SIP was originally developed in 1998 for PyQt - the Python bindings for the Qt GUI toolkit - but is suitable for generating bindings for any C or C++ library. This version of SIP generates bindings for Python v2.3 or later. There are many other similar tools available. One of the original such tools is SWIG and, in fact, SIP is so called because it started out as a small SWIG. Unlike SWIG, SIP is specifically designed for bringing together Python and C/C++ and goes to great lengths to make the integration as tight as possible. The homepage for SIP is http://www.riverbankcomputing.com/software/sip/. Here you will always find the latest stable version, current development snapshots, and the latest version of this documentation. 1.1 LicenseSIP is licensed under the same terms as Python itself. SIP places no restrictions on the license you may apply to the bindings you create. 1.2 FeaturesSIP, and the bindings it produces, have the following features.
1.3 SIP ComponentsSIP comprises a number of different components.
1.4 Qt SupportSIP has specific support for the creation of bindings based on Trolltech's Qt toolkit. The SIP code generator understands the signal/slot type safe callback mechanism that Qt uses to connect objects together. This allows applications to define new Python signals, and allows any Python callable object to be used as a slot. SIP itself does not require Qt to be installed. 2 Potential Incompatibilities with Earlier Versions2.1 SIP v4.7.8This version allows a Python int object to be passed whenever an enum is expected. This can mean that two signatures that were different with prior versions are now the same as far as Python is concerned. The Constrained annotation can now be applied to an enum argument to revert to the earlier behaviour. 2.2 SIP v4.7.3Prior to this version SIP did not automatically generate missing complementary comparison operators. Typically this was worked around by adding them explicitly to the .sip files, even though they weren't implemented in C++ and relied on the C++ compiler calling the complementary operator that was implemented. A necessary change to the code generator meant that this not longer worked and so SIP was changed to automatically generate any missing complementary operators. If you have added such operators explicitly then you should remove them or make them dependent on the particular version of SIP. 2.3 SIP v4.4
3 Installing SIP3.1 Downloading SIPYou can get the latest release of the SIP source code from http://www.riverbankcomputing.com/software/sip/download. SIP is also included with all of the major Linux distributions. However, it may be a version or two out of date. 3.2 Configuring SIPAfter unpacking the source package (either a .tar.gz or a .zip file depending on your platform) you should then check for any README files that relate to your platform. Next you need to configure SIP by executing the configure.py script. For example: python configure.py This assumes that the Python interpreter is on your path. Something like the following may be appropriate on Windows: c:\python26\python configure.py If you have multiple versions of Python installed then make sure you use the interpreter for which you wish SIP to generate bindings for. The full set of command line options is:
The configure.py script takes many other options that allows the build system to be finely tuned. These are of the form name=value or name+=value. The -h option will display each supported name, although not all are applicable to all platforms. The name=value form means that value will replace the existing value of name. The name+=value form means that value will be appended to the existing value of name. For example, the following will disable support for C++ exceptions (and so reduce the size of module binaries) when used with GCC: python configure.py CXXFLAGS+=-fno-exceptions A pure Python module called sipconfig.py is generated by configure.py. This defines each name and its corresponding value. Looking at it will give you a good idea of how the build system uses the different options. It is covered in detail in The SIP Build System. 3.2.1 Configuring SIP Using MinGWSIP, and the modules it generates, can be built with MinGW, the Windows port of GCC. You must use the -p command line option to specify the correct platform. For example: c:\python26\python configure.py -p win32-g++ 3.2.2 Configuring SIP Using the Borland C++ CompilerSIP, and the modules it generates, can be built with the free Borland C++ compiler. You must use the -p command line option to specify the correct platform. For example: c:\python26\python configure.py -p win32-borland You must also make sure you have a Borland-compatible version of the Python library. If you are using the standard Python distribution (built using the Microsoft compiler) then you must convert the format of the Python library. For example: coff2omf python26.lib python26_bcpp.lib 3.3 Building SIPThe next step is to build SIP by running your platform's make command. For example: make The final step is to install SIP by running the following command: make install (Depending on your system you may require root or administrator privileges.) This will install the various SIP components. 4 Using SIPBindings are generated by the SIP code generator from a number of specification files, typically with a .sip extension. Specification files look very similar to C and C++ header files, but often with additional information (in the form of a directive or an annotation) and code so that the bindings generated can be finely tuned. 4.1 A Simple C++ ExampleWe start with a simple example. Let's say you have a (fictional) C++ library that implements a single class called Word. The class has one constructor that takes a \0 terminated character string as its single argument. The class has one method called reverse() which takes no arguments and returns a \0 terminated character string. The interface to the class is defined in a header file called word.h which might look something like this: // Define the interface to the word library. class Word { const char *the_word; public: Word(const char *w); char *reverse() const; }; The corresponding SIP specification file would then look something like this: // Define the SIP wrapper to the word library. %Module word 0 class Word { %TypeHeaderCode #include <word.h> %End public: Word(const char *w); char *reverse() const; }; Obviously a SIP specification file looks very much like a C++ (or C) header file, but SIP does not include a full C++ parser. Let's look at the differences between the two files.
If we want to we can now generate the C++ code in the current directory by running the following command: sip -c . word.sip However, that still leaves us with the task of compiling the generated code and linking it against all the necessary libraries. It's much easier to use the SIP build system to do the whole thing. Using the SIP build system is simply a matter of writing a small Python script. In this simple example we will assume that the word library we are wrapping and it's header file are installed in standard system locations and will be found by the compiler and linker without having to specify any additional flags. In a more realistic example your Python script may take command line options, or search a set of directories to deal with different configurations and installations. This is the simplest script (conventionally called configure.py): import os import sipconfig # The name of the SIP build file generated by SIP and used by the build # system. build_file = "word.sbf" # Get the SIP configuration information. config = sipconfig.Configuration() # Run SIP to generate the code. os.system(" ".join([config.sip_bin, "-c", ".", "-b", build_file, "word.sip"])) # Create the Makefile. makefile = sipconfig.SIPModuleMakefile(config, build_file) # Add the library we are wrapping. The name doesn't include any platform # specific prefixes or extensions (e.g. the "lib" prefix on UNIX, or the # ".dll" extension on Windows). makefile.extra_libs = ["word"] # Generate the Makefile itself. makefile.generate() Hopefully this script is self-documenting. The key parts are the Configuration and SIPModuleMakefile classes. The build system contains other Makefile classes, for example to build programs or to call other Makefiles in sub-directories. After running the script (using the Python interpreter the extension module is being created for) the generated C++ code and Makefile will be in the current directory. To compile and install the extension module, just run the following commands [3]: make make install That's all there is to it. See Building Your Extension with distutils for an example of how to build this example using distutils.
4.2 A Simple C ExampleLet's now look at a very similar example of wrapping a fictional C library: /* Define the interface to the word library. */ struct Word { const char *the_word; }; struct Word *create_word(const char *w); char *reverse(struct Word *word); The corresponding SIP specification file would then look something like this: /* Define the SIP wrapper to the word library. */ %CModule word 0 struct Word { %TypeHeaderCode #include <word.h> %End const char *the_word; }; struct Word *create_word(const char *w) /Factory/; char *reverse(struct Word *word); Again, let's look at the differences between the two files.
The configure.py build system script described in the previous example can be used for this example without change. 4.3 A More Complex C++ ExampleIn this last example we will wrap a fictional C++ library that contains a class that is derived from a Qt class. This will demonstrate how SIP allows a class hierarchy to be split across multiple Python extension modules, and will introduce SIP's versioning system. The library contains a single C++ class called Hello which is derived from Qt's QLabel class. It behaves just like QLabel except that the text in the label is hard coded to be Hello World. To make the example more interesting we'll also say that the library only supports Qt v4.2 and later, and also includes a function called setDefault() that is not implemented in the Windows version of the library. The hello.h header file looks something like this: // Define the interface to the hello library. #include <qlabel.h> #include <qwidget.h> #include <qstring.h> class Hello : public QLabel { // This is needed by the Qt Meta-Object Compiler. Q_OBJECT public: Hello(QWidget *parent, const char *name = 0, WFlags f = 0); private: // Prevent instances from being copied. Hello(const Hello &); Hello &operator=(const Hello &); }; #if !defined(Q_OS_WIN) void setDefault(const QString &def); #endif The corresponding SIP specification file would then look something like this: // Define the SIP wrapper to the hello library. %Module hello 0 %Import QtCore/QtCoremod.sip %If (Qt_4_2_0 -) class Hello : QLabel { %TypeHeaderCode #include <hello.h> %End public: Hello(QWidget *parent /TransferThis/, const char *name = 0, WFlags f = 0); private: Hello(const Hello &); }; %If (!WS_WIN) void setDefault(const QString &def); %End %End Again we look at the differences, but we'll skip those that we've looked at in previous examples.
One question you might have at this point is why bother to define the private copy constructor when it can never be called from Python? The answer is to prevent the automatic generation of a public copy constructor. We now look at the configure.py script. This is a little different to the script in the previous examples for two related reasons. Firstly, PyQt includes a pure Python module called pyqtconfig that extends the SIP build system for modules, like our example, that build on top of PyQt. It deals with the details of which version of Qt is being used (i.e. it determines what the correct tags are) and where it is installed. This is called a module's configuration module. Secondly, we generate a configuration module (called helloconfig) for our own hello module. There is no need to do this, but if there is a chance that somebody else might want to extend your C++ library then it would make life easier for them. Now we have two scripts. First the configure.py script: import os import sipconfig import pyqtconfig # The name of the SIP build file generated by SIP and used by the build # system. build_file = "hello.sbf" # Get the PyQt configuration information. config = pyqtconfig.Configuration() # Get the extra SIP flags needed by the imported qt module. Note that # this normally only includes those flags (-x and -t) that relate to SIP's # versioning system. qt_sip_flags = config.pyqt_qt_sip_flags # Run SIP to generate the code. Note that we tell SIP where to find the qt # module's specification files using the -I flag. os.system(" ".join([config.sip_bin, "-c", ".", "-b", build_file, "-I", config.pyqt_sip_dir, qt_sip_flags, "hello.sip"])) # We are going to install the SIP specification file for this module and # its configuration module. installs = [] installs.append(["hello.sip", os.path.join(config.default_sip_dir, "hello")]) installs.append(["helloconfig.py", config.default_mod_dir]) # Create the Makefile. The QtModuleMakefile class provided by the # pyqtconfig module takes care of all the extra preprocessor, compiler and # linker flags needed by the Qt library. makefile = pyqtconfig.QtModuleMakefile( configuration=config, build_file=build_file, installs=installs ) # Add the library we are wrapping. The name doesn't include any platform # specific prefixes or extensions (e.g. the "lib" prefix on UNIX, or the # ".dll" extension on Windows). makefile.extra_libs = ["hello"] # Generate the Makefile itself. makefile.generate() # Now we create the configuration module. This is done by merging a Python # dictionary (whose values are normally determined dynamically) with a # (static) template. content = { # Publish where the SIP specifications for this module will be # installed. "hello_sip_dir": config.default_sip_dir, # Publish the set of SIP flags needed by this module. As these are the # same flags needed by the qt module we could leave it out, but this # allows us to change the flags at a later date without breaking # scripts that import the configuration module. "hello_sip_flags": qt_sip_flags } # This creates the helloconfig.py module from the helloconfig.py.in # template and the dictionary. sipconfig.create_config_module("helloconfig.py", "helloconfig.py.in", content) Next we have the helloconfig.py.in template script: import pyqtconfig # These are installation specific values created when Hello was configured. # The following line will be replaced when this template is used to create # the final configuration module. # @SIP_CONFIGURATION@ class Configuration(pyqtconfig.Configuration): """The class that represents Hello configuration values. """ def __init__(self, sub_cfg=None): """Initialise an instance of the class. sub_cfg is the list of sub-class configurations. It should be None when called normally. """ # This is all standard code to be copied verbatim except for the # name of the module containing the super-class. if sub_cfg: cfg = sub_cfg else: cfg = [] cfg.append(_pkg_config) pyqtconfig.Configuration.__init__(self, cfg) class HelloModuleMakefile(pyqtconfig.QtModuleMakefile): """The Makefile class for modules that %Import hello. """ def finalise(self): """Finalise the macros. """ # Make sure our C++ library is linked. self.extra_libs.append("hello") # Let the super-class do what it needs to. pyqtconfig.QtModuleMakefile.finalise(self) Again, we hope that the scripts are self documenting.
4.4 Ownership of ObjectsWhen a C++ instance is wrapped a corresponding Python object is created. The Python object behaves as you would expect in regard to garbage collection - it is garbage collected when its reference count reaches zero. What then happens to the corresponding C++ instance? The obvious answer might be that the instance's destructor is called. However the library API may say that when the instance is passed to a particular function, the library takes ownership of the instance, i.e. responsibility for calling the instance's destructor is transferred from the SIP generated module to the library. Ownership of an instance may also be associated with another instance. The implication being that the owned instance will automatically be destroyed if the owning instance is destroyed. SIP keeps track of these relationships to ensure that Python's cyclic garbage collector can detect and break any reference cycles between the owning and owned instances. The association is implemented as the owning instance taking a reference to the owned instance. The TransferThis, Transfer and TransferBack annotations are used to specify where, and it what direction, transfers of ownership happen. It is very important that these are specified correctly to avoid crashes (where both Python and C++ call the destructor) and memory leaks (where neither Python and C++ call the destructor). This applies equally to C structures where the structure is returned to the heap using the free() function. See also sipTransferTo(), sipTransferBack() and sipTransferBreak(). 4.5 Support for Python's Buffer InterfaceSIP supports Python's buffer interface in that whenever C/C++ requires a char or char * type then any Python type that supports the buffer interface (including ordinary Python strings) can be used. If a buffer is made up of a number of segments then all but the first will be ignored. 4.6 Support for Wide CharactersSIP v4.6 introduced support for wide characters (i.e. the wchar_t type). Python's C API includes support for converting between unicode objects and wide character strings and arrays. When converting from a unicode object to wide characters SIP creates the string or array on the heap (using memory allocated using sipMalloc()). This then raises the problem of how this memory is subsequently freed. The following describes how SIP handles this memory in the different situations where this is an issue.
4.7 The Python Global Interpreter LockPython's Global Interpretor Lock (GIL) must be acquired before calls can be made to the Python API. It should also be released when a potentially blocking call to C/C++ library is made in order to allow other Python threads to be executed. In addition, some C/C++ libraries may implement their own locking strategies that conflict with the GIL causing application deadlocks. SIP provides ways of specifying when the GIL is released and acquired to ensure that locking problems can be avoided. SIP always ensures that the GIL is acquired before making calls to the Python API. By default SIP does not release the GIL when making calls to the C/C++ library being wrapped. The ReleaseGIL annotation can be used to override this behaviour when required. If SIP is given the -g command line option then the default behaviour is changed and SIP releases the GIL every time is makes calls to the C/C++ library being wrapped. The HoldGIL annotation can be used to override this behaviour when required. 5 The SIP Command LineThe syntax of the SIP command line is: sip [options] [specification] specification is the name of the specification file for the module. If it is omitted then stdin is used. The full set of command line options is:
6 SIP Specification FilesA SIP specification consists of some C/C++ type and function declarations and some directives. The declarations may contain annotations which provide SIP with additional information that cannot be expressed in C/C++. SIP does not include a full C/C++ parser. It is important to understand that a SIP specification describes the Python API, i.e. the API available to the Python programmer when they import the generated module. It does not have to accurately represent the underlying C/C++ library. There is nothing wrong with omitting functions that make little sense in a Python context, or adding functions implemented with handwritten code that have no C/C++ equivalent. It is even possible (and sometimes necessary) to specify a different super-class hierarchy for a C++ class. All that matters is that the generated code compiles properly. In most cases the Python API matches the C/C++ API. In some cases handwritten code (see %MethodCode) is used to map from one to the other without SIP having to know the details itself. However, there are a few cases where SIP generates a thin wrapper around a C++ method or constructor (see Generated Derived Classes) and needs to know the exact C++ signature. To deal with these cases SIP allows two signatures to be specified. For example: class Klass { public: // The Python signature is a tuple, but the underlying C++ signature // is a 2 element array. Klass(SIP_PYTUPLE) [(int *)]; %MethodCode int iarr[2]; if (PyArg_ParseTuple(a0, "ii", &iarr[0], &iarr[1])) { // Note that we use the SIP generated derived class // constructor. Py_BEGIN_ALLOW_THREADS sipCpp = new sipKlass(iarr); Py_END_ALLOW_THREADS } %End }; 6.1 Syntax DefinitionThe following is a semi-formal description of the syntax of a specification file. specification ::= {module-statement} module-statement ::= [module-directive | statement] module-directive ::= [%CModule | %CompositeModule | %ConsolidatedModule | %Copying | %Doc | %ExportedDoc | %ExportedHeaderCode | %Feature | %Import | %Include | %License | %MappedType | mapped-type-template | %Module | %ModuleCode | %ModuleHeaderCode | %OptionalInclude | %Platforms | %PreInitialisationCode | %PostInitialisationCode | sip-option-list | %Timeline | %UnitCode] sip-option-list :: %SIPOptions ( option-list ) option-list ::= option [, option-list] statement :: [class-statement | function | variable] class-statement :: [%If | class | class-template | enum | namespace | opaque-class | operator | struct | typedef | exception] class ::= class name [: super-classes] [class-annotations] { {class-line} }; super-classes ::= name [, super-classes] class-line ::= [class-statement | %BIGetReadBufferCode | %BIGetWriteBufferCode | %BIGetSegCountCode | %BIGetCharBufferCode | %ConvertToSubClassCode | %ConvertToTypeCode | %GCClearCode | %GCTraverseCode | %PickleCode | %TypeCode | %TypeHeaderCode | constructor | destructor | method | static-method | virtual-method | special-method | operator | virtual-operator | class-variable | public: | public slots: | protected: | protected slots: | private: | private slots: | signals:] constructor ::= [explicit] name ( [argument-list] ) [exceptions] [function-annotations] [c++-constructor-signature] ; [%MethodCode] c++-constructor-signature ::= [( [argument-list] )] destructor ::= [virtual] ~ name () [exceptions] [= 0] [function-annotations] ; [%MethodCode] [%VirtualCatcherCode] method ::= type name ( [argument-list] ) [const] [exceptions] [= 0] [function-annotations] [c++-signature] ; [%MethodCode] c++-signature ::= [ type ( [argument-list] )] static-method ::= static function virtual-method ::= virtual type name ( [argument-list] ) [const] [exceptions] [= 0] [function-annotations] [c++-signature] ; [%MethodCode] [%VirtualCatcherCode] special-method ::= type special-method-name ( [argument-list] ) [function-annotations] ; [%MethodCode] special-method-name ::= [ __abs__ | __add__ | __and__ | __call__ | __cmp__ | __contains__ | __delitem__ | __div__ | __eq__ | __float__ | __ge__ | __getitem__ | __gt__ | __hash__ | __iadd__ | __iand__ | __idiv__ | __ilshift__ | __imod__ | __imul__ | __int__ | __invert__ | __ior__ | __irshift__ | __isub__ | __ixor__ | __le__ | __len__ | __long__ | __lshift__ | __lt__ | __mod__ | __mul__ | __ne__ | __neg__ | __nonzero__ | __or__ | __pos__ | __repr__ | __rshift__ | __setitem__ | __str__ | __sub__ | __xor__] operator ::= operator-type ( [argument-list] ) [const] [exceptions] [function-annotations] ; [%MethodCode] virtual-operator ::= virtual operator-type ( [argument-list] ) [const] [exceptions] [= 0] [function-annotations] ; [%MethodCode] [%VirtualCatcherCode] operatator-type ::= [ operator-function | operator-cast ] operator-function ::= type operator operator-name operator-cast ::= operator type operator-name ::= [+ | - | * | / | % | & | | | ^ | << | >> | += | -= | *= | /= | %= | &= | |= | ^= | <<= | >>= | ~ | () | [] | < | <= | == | != | > | >>=] class-variable ::= [static] variable class-template :: = template < type-list > class mapped-type-template :: = template < type-list > %MappedType enum ::= enum [name] [enum-annotations] { {enum-line} }; enum-line ::= [%If | name [enum-annotations] , function ::= type name ( [argument-list] ) [exceptions] [function-annotations] ; [%MethodCode] namespace ::= namespace name { {namespace-line} }; namespace-line ::= [%TypeHeaderCode | statement] opaque-class ::= class scoped-name ; struct ::= struct name { {class-line} }; typedef ::= typedef [typed-name | function-pointer] typedef-annotations ; variable::= typed-name [variable-annotations] ; [%AccessCode] [%GetCode] [%SetCode] exception ::= %Exception exception-name [exception-base] { [%TypeHeaderCode] %RaiseCode };` exception-name ::= scoped-name exception-base ::= ( [exception-name | python-exception] ) python-exception ::= [SIP_Exception | SIP_StopIteration | SIP_StandardError | SIP_ArithmeticError | SIP_LookupError | SIP_AssertionError | SIP_AttributeError | SIP_EOFError | SIP_FloatingPointError | SIP_EnvironmentError | SIP_IOError | SIP_OSError | SIP_ImportError | SIP_IndexError | SIP_KeyError | SIP_KeyboardInterrupt | SIP_MemoryError | SIP_NameError | SIP_OverflowError | SIP_RuntimeError | SIP_NotImplementedError | SIP_SyntaxError | SIP_IndentationError | SIP_TabError | SIP_ReferenceError | SIP_SystemError | SIP_SystemExit | SIP_TypeError | SIP_UnboundLocalError | SIP_UnicodeError | SIP_UnicodeEncodeError | SIP_UnicodeDecodeError | SIP_UnicodeTranslateError | SIP_ValueError | SIP_ZeroDivisionError | SIP_WindowsError | SIP_VMSError] exceptions ::= throw ( [exception-list] ) exception-list ::= scoped-name [, exception-list] argument-list ::= argument [, argument-list] [, ...] argument ::= [type [name] [argument-annotations] [default-value] | SIP_ANYSLOT [default-value] | SIP_QOBJECT | SIP_RXOBJ_CON | SIP_RXOBJ_DIS | SIP_SIGNAL [default-value] | SIP_SLOT [default-value] | SIP_SLOT_CON | SIP_SLOT_DIS] default-value ::= = expression expression ::= [value | value binary-operator expression] value ::= [unary-operator] simple-value simple-value ::= [scoped-name | function-call | real-value | integer-value | boolean-value | string-value | character-value] typed-name::= type name function-pointer::= type (* name )( [type-list] ) type-list ::= type [, type-list] function-call ::= scoped-name ( [value-list] ) value-list ::= value [, value-list] real-value ::= a floating point number integer-value ::= a number boolean-value ::= [true | false] string-value ::= " {character} " character-value ::= ` character ` unary-operator ::= [! | ~ | - | +] binary-operator ::= [- | + | * | / | & | |] argument-annotations ::= see Argument Annotations class-annotations ::= see Class Annotations enum-annotations ::= see Enum Annotations function-annotations ::= see Function Annotations typedef-annotations ::= see Typedef Annotations variable-annotations ::= see Variable Annotations type ::= [const] base-type {*} [&] type-list ::= type [, type-list] base-type ::= [scoped-name | template | struct scoped-name | short | unsigned short | int | unsigned | unsigned int | long | unsigned long | float | double | bool | char | signed char | unsigned char | void | wchar_t | SIP_PYCALLABLE | SIP_PYDICT | SIP_PYLIST | SIP_PYOBJECT | SIP_PYSLICE | SIP_PYTUPLE | SIP_PYTYPE] scoped-name ::= name [:: scoped-name] template ::= scoped-name < type-list > name ::= _A-Za-z {_A-Za-z0-9} Here is a short list of differences between C++ and the subset supported by SIP that might trip you up.
6.2 Variable Numbers of ArgumentsSIP supports the use of ... as the last part of a function signature. Any remaining arguments are collected as a Python tuple. 6.3 Additional SIP TypesSIP supports a number of additional data types that can be used in Python signatures. 6.3.1 SIP_ANYSLOTThis is both a const char * and a PyObject * that is used as the type of the member instead of const char * in functions that implement the connection or disconnection of an explicitly generated signal to a slot. Handwritten code must be provided to interpret the conversion correctly. 6.3.2 SIP_PYCALLABLEThis is a PyObject * that is a Python callable object. 6.3.3 SIP_PYDICTThis is a PyObject * that is a Python dictionary object. 6.3.4 SIP_PYLISTThis is a PyObject * that is a Python list object. 6.3.5 SIP_PYOBJECTThis is a PyObject * of any Python type. 6.3.6 SIP_PYSLICEThis is a PyObject * that is a Python slice object. 6.3.7 SIP_PYTUPLEThis is a PyObject * that is a Python tuple object. 6.3.8 SIP_PYTYPEThis is a PyObject * that is a Python type object. 6.3.9 SIP_QOBJECTThis is a QObject * that is a C++ instance of a class derived from Qt's QObject class. 6.3.10 SIP_RXOBJ_CONThis is a QObject * that is a C++ instance of a class derived from Qt's QObject class. It is used as the type of the receiver instead of const QObject * in functions that implement a connection to a slot. 6.3.11 SIP_RXOBJ_DISThis is a QObject * that is a C++ instance of a class derived from Qt's QObject class. It is used as the type of the receiver instead of const QObject * in functions that implement a disconnection from a slot. 6.3.12 SIP_SIGNALThis is a const char * that is used as the type of the signal instead of const char * in functions that implement the connection or disconnection of an explicitly generated signal to a slot. 6.3.13 SIP_SLOTThis is a const char * that is used as the type of the member instead of const char * in functions that implement the connection or disconnection of an explicitly generated signal to a slot. 6.3.14 SIP_SLOT_CONThis is a const char * that is used as the type of the member instead of const char * in functions that implement the connection of an internally generated signal to a slot. The type includes a comma separated list of types that is the C++ signature of of the signal. To take an example, QAccel::connectItem() connects an internally generated signal to a slot. The signal is emitted when the keyboard accelerator is activated and it has a single integer argument that is the ID of the accelerator. The C++ signature is: bool connectItem(int id, const QObject *receiver, const char *member); The corresponding SIP specification is: bool connectItem(int, SIP_RXOBJ_CON, SIP_SLOT_CON(int)); 6.3.15 SIP_SLOT_DISThis is a const char * that is used as the type of the member instead of const char * in functions that implement the disconnection of an internally generated signal to a slot. The type includes a comma separated list of types that is the C++ signature of of the signal. 7 SIP DirectivesIn this section we describe each of the directives that can be used in specification files. All directives begin with % as the first non-whitespace character in a line. Some directives have arguments or contain blocks of code or documentation. In the following descriptions these are shown in italics. Optional arguments are enclosed in [brackets]. Some directives are used to specify handwritten code. Handwritten code must not define names that start with the prefix sip. 7.1 %AccessCode%AccessCode code %End This directive is used immediately after the declaration of an instance of a wrapped class or structure, or a pointer to such an instance. You use it to provide handwritten code that overrides the default behaviour. For example: class Klass; Klass *klassInstance; %AccessCode // In this contrived example the C++ library we are wrapping defines // klassInstance as Klass ** (which SIP doesn't support) so we // explicitly dereference it. if (klassInstance && *klassInstance) return *klassInstance; // This will get converted to None. return 0; %End 7.2 %BIGetCharBufferCode%BIGetCharBufferCode code %End This directive (along with %BIGetReadBufferCode, %BIGetSegCountCode and %BIGetWriteBufferCode) is used to specify code that implements Python's buffer interface. See the section Buffer Object Structures for the details. The following variables are made available to the handwritten code:
7.3 %BIGetReadBufferCode%BIGetReadBufferCode code %End This directive (along with %BIGetCharBufferCode, %BIGetSegCountCode and %BIGetWriteBufferCode) is used to specify code that implements Python's buffer interface. The following variables are made available to the handwritten code:
7.4 %BIGetSegCountCode%BIGetSegCountCode code %End This directive (along with %BIGetCharBufferCode, %BIGetReadBufferCode and %BIGetWriteBufferCode) is used to specify code that implements Python's buffer interface. The following variables are made available to the handwritten code:
7.5 %BIGetWriteBufferCode%BIGetWriteBufferCode code %End This directive (along with %BIGetCharBufferCode, %BIGetReadBufferCode and %BIGetSegCountCode is used to specify code that implements Python's buffer interface. The following variables are made available to the handwritten code:
7.6 %CModule%CModule name [version] This directive is used to identify that the library being wrapped is a C library and to define the name of the module and it's optional version number. See the %Module directive for an explanation of the version number. For example: %CModule dbus 1 7.7 %CompositeModule%CompositeModule name A composite module is one that merges a number of related SIP generated modules. For example, a module that merges the modules a_mod, b_mod and c_mod is equivalent to the following pure Python module: from a_mod import * from b_mod import * from c_mod import * Clearly the individual modules should not define module-level objects with the same name. This directive is used to specify the name of a composite module. Any subsequent %CModule or %Module directive is interpreted as defining a component module. For example: %CompositeModule PyQt4.Qt %Include QtCore/QtCoremod.sip %Include QtGui/QtGuimod.sip The main purpose of a composite module is as a programmer convenience as they don't have to remember which which individual module an object is defined in. 7.8 %ConsolidatedModule%ConsolidatedModule name A consolidated module is one that consolidates the wrapper code of a number of SIP generated modules (refered to as component modules in this context). This directive is used to specify the name of a consolidated module. Any subsequent %CModule or %Module directive is interpreted as defining a component module. For example: %ConsolidatedModule PyQt4._qt %Include QtCore/QtCoremod.sip %Include QtGui/QtGuimod.sip A consolidated module is not intended to be explicitly imported by an application. Instead it is imported by its component modules when they themselves are imported. Normally the wrapper code is contained in the component module and is linked against the corresponding C or C++ library. The advantage of a consolidated module is that it allows all of the wrapped C or C++ libraries to be linked against a single module. If the linking is done statically then deployment of generated modules can be greatly simplified. It follows that a component module can be built in one of two ways, as a normal standalone module, or as a component of a consolidated module. When building as a component the -p command line option should be used to specify the name of the consolidated module. 7.9 %ConvertFromTypeCode%ConvertFromTypeCode code %End This directive is used as part of the %MappedType directive to specify the handwritten code that converts an instance of a mapped type to a Python object. The following variables are made available to the handwritten code:
The handwritten code must explicitly return a PyObject *. If there was an error then a Python exception must be raised and NULL returned. The following example converts a QList<QWidget *> instance to a Python list of QWidget instances: %ConvertFromTypeCode PyObject *l; // Create the Python list of the correct length. if ((l = PyList_New(sipCpp -> size())) == NULL) return NULL; // Go through each element in the C++ instance and convert it to a // wrapped QWidget. for (int i = 0; i < sipCpp -> size(); ++i) { QWidget *w = sipCpp -> at(i); PyObject *wobj; // Get the Python wrapper for the QWidget instance, creating a new // one if necessary, and handle any ownership transfer. if ((wobj = sipConvertFromInstance(w, sipClass_QWidget, sipTransferObj)) == NULL) { // There was an error so garbage collect the Python list. Py_DECREF(l); return NULL; } // Add the wrapper to the list. PyList_SET_ITEM(l, i, wobj); } // Return the Python list. return l; %End 7.10 %ConvertToSubClassCode%ConvertToSubClassCode code %End When SIP needs to wrap a C++ class instance it first checks to make sure it hasn't already done so. If it has then it just returns a new reference to the corresponding Python object. Otherwise it creates a new Python object of the appropriate type. In C++ a function may be defined to return an instance of a certain class, but can often return a sub-class instead. This directive is used to specify handwritten code that exploits any available real-time type information (RTTI) to see if there is a more specific Python type that can be used when wrapping the C++ instance. The RTTI may be provided by the compiler or by the C++ instance itself. The directive is included in the specification of one of the classes that the handwritten code handles the type conversion for. It doesn't matter which one, but a sensible choice would be the one at the root of that class hierarchy in the module. Note that if a class hierarchy extends over a number of modules then this directive should be used in each of those modules to handle the part of the hierarchy defined in that module. SIP will ensure that the different pieces of code are called in the right order to determine the most specific Python type to use. The following variables are made available to the handwritten code:
The handwritten code must not explicitly return. The following example shows the sub-class conversion code for QEvent based class hierarchy in PyQt: class QEvent { %ConvertToSubClassCode // QEvent sub-classes provide a unique type ID. switch (sipCpp -> type()) { case QEvent::Timer: sipClass = sipClass_QTimerEvent; break; case QEvent::KeyPress: case QEvent::KeyRelease: sipClass = sipClass_QKeyEvent; break; // Skip the remaining event types to keep the example short. default: // We don't recognise the type. sipClass = NULL; } %End // The rest of the class specification. }; The SIP API includes the sipMapIntToClass() and sipMapStringToClass() functions that convert integer and string based RTTI to Python type objects based on ordered lookup tables. 7.11 %ConvertToTypeCode%ConvertToTypeCode code %End This directive is used to specify the handwritten code that converts a Python object to a mapped type instance and to handle any ownership transfers. It is used as part of the %MappedType directive and as part of a class specification. The code is also called to determine if the Python object is of the correct type prior to conversion. When used as part of a class specification it can automatically convert additional types of Python object. For example, PyQt uses it in the specification of the QString class to allow Python string objects and unicode objects to be used wherever QString instances are expected. The following variables are made available to the handwritten code:
The handwritten code must explicitly return an int the meaning of which depends on the value of sipIsErr. If sipIsErr is NULL then a non-zero value is returned if the Python object has a type that can be converted to the mapped type. Otherwise zero is returned. If sipIsErr is not NULL then a combination of the following flags is returned.
The following example converts a Python list of QPoint instances to a QList<QPoint> instance: %ConvertToTypeCode // See if we are just being asked to check the type of the Python // object. if (!sipIsErr) { // Checking whether or not None has been passed instead of a list // has already been done. if (!PyList_Check(sipPy)) return 0; // Check the type of each element. We specify SIP_NOT_NONE to // disallow None because it is a list of QPoint, not of a pointer // to a QPoint, so None isn't appropriate. for (int i = 0; i < PyList_GET_SIZE(sipPy); ++i) if (!sipCanConvertToInstance(PyList_GET_ITEM(sipPy, i), sipClass_QPoint, SIP_NOT_NONE)) return 0; // The type is valid. return 1; } // Create the instance on the heap. QList<QPoint> *ql = new QList<QPoint>; for (int i = 0; i < PyList_GET_SIZE(sipPy); ++i) { QPoint *qp; int state; // Get the address of the element's C++ instance. Note that, in // this case, we don't apply any ownership changes to the list // elements, only to the list itself. qp = reinterpret_cast<QPoint *>(sipConvertToInstance( PyList_GET_ITEM(sipPy, i), sipClass_QPoint, 0, SIP_NOT_NONE, &state, sipIsErr)); // Deal with any errors. if (*sipIsErr) { sipReleaseInstance(qp, sipClass_QPoint, state); // Tidy up. delete ql; // There is no temporary instance. return 0; } ql -> append(*qp); // A copy of the QPoint was appended to the list so we no longer // need it. It may be a temporary instance that should be // destroyed, or a wrapped instance that should not be destroyed. // sipReleaseInstance() will do the right thing. sipReleaseInstance(qp, sipClass_QPoint, state); } // Return the instance. *sipCppPtr = ql; // The instance should be regarded as temporary (and be destroyed as // soon as it has been used) unless it has been transferred from // Python. sipGetState() is a convenience function that implements // this common transfer behaviour. return sipGetState(sipTransferObj); %End When used in a class specification the handwritten code replaces the code that would normally be automatically generated. This means that the handwritten code must also handle instances of the class itself and not just the additional types that are being supported. This should be done by making calls to sipCanConvertToInstance() to check the object type and sipConvertToInstance() to convert the object. The SIP_NO_CONVERTORS flag must be passed to both these functions to prevent recursive calls to the handwritten code. 7.12 %Copying%Copying text %End This directive is used to specify some arbitrary text that will be included at the start of all source files generated by SIP. It is normally used to include copyright and licensing terms. For example: %Copying Copyright (c) 2007 Riverbank Computing Limited %End 7.13 %Doc%Doc text %End This directive is used to specify some arbitrary text that will be extracted by SIP when the -d command line option is used. The directive can be specified any number of times and SIP will concatenate all the separate pieces of text in the order that it sees them. Documentation that is specified using this directive is local to the module in which it appears. It is ignored by modules that %Import it. Use the %ExportedDoc directive for documentation that should be included by all modules that %Import this one. For example: %Doc <h1>An Example</h1> <p> This fragment of documentation is HTML and is local to the module in which it is defined. </p> %End 7.14 %EndThis isn't a directive in itself, but is used to terminate a number of directives that allow a block of handwritten code or text to be specified. 7.15 %Exception%Exception name [(base-exception)] { [*header-code] raise-code }; This directive is used to define new Python exceptions, or to provide a stub for existing Python exceptions. It allows handwritten code to be provided that implements the translation between C++ exceptions and Python exceptions. The arguments to throw () specifiers must either be names of classes or the names of Python exceptions defined by this directive. name is the name of the exception. base-exception is the optional base exception. This may be either one of the standard Python exceptions or one defined with a previous %Exception directive. header-code is the optional %TypeHeaderCode used to specify any external interface to the exception being defined. raise-code is the %RaiseCode used to specify the handwritten code that converts a reference to the C++ exception to the Python exception. For example: %Exception std::exception(SIP_Exception) /PyName=StdException/ { %TypeHeaderCode #include <exception> %End %RaiseCode const char *detail = sipExceptionRef.what(); SIP_BLOCK_THREADS PyErr_SetString(sipException_std_exception, detail); SIP_UNBLOCK_THREADS %End }; In this example we map the standard C++ exception to a new Python exception. The new exception is called StdException and is derived from the standard Python exception Exception. 7.16 %ExportedDoc%ExportedDoc text %End This directive is used to specify some arbitrary text that will be extracted by SIP when the -d command line option is used. The directive can be specified any number of times and SIP will concatenate all the separate pieces of text in the order that it sees them. Documentation that is specified using this directive will also be included by modules that %Import it. For example: %ExportedDoc ========== An Example ========== This fragment of documentation is reStructuredText and will appear in the module in which it is defined and all modules that %Import it. %End 7.17 %ExportedHeaderCode%ExportedHeaderCode code %End This directive is used to specify handwritten code, typically the declarations of types, that is placed in a header file that is included by all generated code for all modules. It should not include function declarations because Python modules should not explicitly call functions in another Python module. See also %ModuleCode and %ModuleHeaderCode. 7.18 %Feature%Feature name This directive is used to declare a feature. Features (along with %Platforms and %Timeline) are used by the %If directive to control whether or not parts of a specification are processed or ignored. Features are mutually independent of each other - any combination of features may be enabled or disable. By default all features are enabled. The SIP -x command line option is used to disable a feature. If a feature is enabled then SIP will automatically generate a corresponding C preprocessor symbol for use by handwritten code. The symbol is the name of the feature prefixed by SIP_FEATURE_. For example: %Feature FOO_SUPPORT %If (FOO_SUPPORT) void foo(); %End 7.19 %GCClearCode%GCClearCode code %End Python has a cyclic garbage collector which can identify and release unneeded objects even when their reference counts are not zero. If a wrapped C structure or C++ class keeps its own reference to a Python object then, if the garbage collector is to do its job, it needs to provide some handwritten code to traverse and potentially clear those embedded references. See the section Supporting cyclic garbage collection in Embedding and Extending the Python Interpreter for the details. This directive is used to specify the code that clears any embedded references. (See %GCTraverseCode for specifying the code that traverses any embedded references.) The following variables are made available to the handwritten code:
The following simplified example is taken from PyQt. The QCustomEvent class allows arbitary data to be attached to the event. In PyQt this data is always a Python object and so should be handled by the garbage collector: %GCClearCode PyObject *obj; // Get the object. obj = reinterpret_cast<PyObject *>(sipCpp -> data()); // Clear the pointer. sipCpp -> setData(0); // Clear the reference. Py_XDECREF(obj); // Report no error. sipRes = 0; %End 7.20 %GCTraverseCode%GCTraverseCode code %End This directive is used to specify the code that traverses any embedded references for Python's cyclic garbage collector. (See %GCClearCode for a full explanation.) The following variables are made available to the handwritten code:
The following simplified example is taken from PyQt's QCustomEvent class: %GCTraverseCode PyObject *obj; // Get the object. obj = reinterpret_cast<PyObject *>(sipCpp -> data()); // Call the visit function if there was an object. if (obj) sipRes = sipVisit(obj, sipArg); else sipRes = 0; %End 7.21 %GetCode%GetCode code %End This directive is used after the declaration of a C++ class variable or C structure member to specify handwritten code to convert it to a Python object. It is usually used to handle types that SIP cannot deal with automatically. The following variables are made available to the handwritten code:
For example: struct Entity { /* * In this contrived example the C library we are wrapping actually * defines this as char buffer[100] which SIP cannot handle * automatically. */ char *buffer; %GetCode sipPy = PyString_FromStringAndSize(sipCpp -> buffer, 100); %End %SetCode char *ptr; int length; if (PyString_AsStringAndSize(sipPy, &ptr, &length) == -1) sipErr = 1; else if (length != 100) { /* * Raise an exception because the length isn't exactly right. */ PyErr_SetString(PyExc_ValueError, "an Entity.buffer must be exactly 100 bytes"); sipErr = 1; } else memcpy(sipCpp -> buffer, ptr, 100); %End } 7.22 %If%If (expression) specification %End where expression ::= [ored-qualifiers | range] ored-qualifiers ::= [qualifier | qualifier || ored-qualifiers] qualifier ::= [!] [feature | platform] range ::= [version] - [version] This directive is used in conjunction with features (see %Feature), platforms (see %Platforms) and versions (see %Timeline) to control whether or not parts of a specification are processed or not. A range of versions means all versions starting with the lower bound up to but excluding the upper bound. If the lower bound is omitted then it is interpreted as being before the earliest version. If the upper bound is omitted then it is interpreted as being after the latest version. For example: %Feature SUPPORT_FOO %Platforms {WIN32_PLATFORM POSIX_PLATFORM MACOS_PLATFORM} %Timeline {V1_0 V1_1 V2_0 V3_0} %If (!SUPPORT_FOO) // Process this if the SUPPORT_FOO feature is disabled. %End %If (POSIX_PLATFORM || MACOS_PLATFORM) // Process this if either the POSIX_PLATFORM or MACOS_PLATFORM // platforms are enabled. %End %If (V1_0 - V2_0) // Process this if either V1_0 or V1_1 is enabled. %End %If (V2_0 - ) // Process this if either V2_0 or V3_0 is enabled. %End %If ( - ) // Always process this. %End Note that this directive is not implemented as a preprocessor. Only the following parts of a specification are affected by it:
Also note that the only way to specify the logical and of qualifiers is to use nested %If directives. 7.23 %Import%Import filename This directive is used to import the specification of another module. This is needed if the current module makes use of any types defined in the imported module, e.g. as an argument to a function, or to sub-class. If filename cannot be opened then SIP prepends filename with the name of the directory containing the current specification file (i.e. the one containing the %Import directive) and tries again. If this also fails then SIP prepends filename with each of the directories, in turn, specified by the -I command line option. For example: %Import qt/qtmod.sip 7.24 %Include%Include filename This directive is used to include contents of another file as part of the specification of the current module. It is the equivalent of the C preprocessor's #include directive and is used to structure a large module specification into manageable pieces. %Include follows the same search process as %Import when trying to open filename. For example: %Include qwidget.sip 7.25 %License%License /license-annotations/ This directive is used to specify the contents of an optional license dictionary. The license dictionary is called __license__ and is stored in the module dictionary. The elements of the dictionary are specified using the Licensee, Signature, Timestamp and Type annotations. Only the Type annotation is compulsory. Note that this directive isn't an attempt to impose any licensing restrictions on a module. It is simply a method for easily embedding licensing information in a module so that it is accessible to Python scripts. For example: %License /Type="GPL"/ 7.26 %MappedTypetemplate<type-list> %MappedType type { [header-code] [convert-to-code] [convert-from-code] }; %MappedType type { [header-code] [convert-to-code] [convert-from-code] }; This directive is used to define an automatic mapping between a C or C++ type and a Python type. It can be used as part of a template, or to map a specific type. When used as part of a template type cannot itself refer to a template. Any occurrences of any of the type names (but not any * or &) in type-list will be replaced by the actual type names used when the template is instantiated. Template mapped types are instantiated automatically as required (unlike template classes which are only instantiated using typedef). Any explicit mapped type will be used in preference to any template that maps the same type, ie. a template will not be automatically instantiated if there is an explicit mapped type. header-code is the %TypeHeaderCode used to specify the library interface to the type being mapped. convert-to-code is the %ConvertToTypeCode used to specify the handwritten code that converts a Python object to an instance of the mapped type. convert-from-code is the %ConvertFromTypeCode used to specify the handwritten code that converts an instance of the mapped type to a Python object. For example: template<Type *> %MappedType QList { %TypeHeaderCode // Include the library interface to the type being mapped. #include <qlist.h> %End %ConvertToTypeCode // See if we are just being asked to check the type of the Python // object. if (sipIsErr == NULL) { // Check it is a list. if (!PyList_Check(sipPy)) return 0; // Now check each element of the list is of the type we expect. // The template is for a pointer type so we don't disallow None. for (int i = 0; i < PyList_GET_SIZE(sipPy); ++i) if (!sipCanConvertToInstance(PyList_GET_ITEM(sipPy, i), sipClass_Type, 0)) return 0; return 1; } // Create the instance on the heap. QList<Type *> *ql = new QList<Type *>; for (int i = 0; i < PyList_GET_SIZE(sipPy); ++i) { // Use the SIP API to convert the Python object to the // corresponding C++ instance. Note that we apply any ownership // transfer to the list itself, not the individual elements. Type *t = reinterpret_cast<Type *>(sipConvertToInstance( PyList_GET_ITEM(sipPy, i), sipClass_Type, 0, 0, 0, sipIsErr)); if (*sipIsErr) { // Tidy up. delete ql; // There is nothing on the heap. return 0; } // Add the pointer to the C++ instance. ql -> append(t); } // Return the instance on the heap. *sipCppPtr = ql; // Apply the normal transfer. return sipGetState(sipTransferObj); %End %ConvertFromTypeCode PyObject *l; // Create the Python list of the correct length. if ((l = PyList_New(sipCpp -> size())) == NULL) return NULL; // Go through each element in the C++ instance and convert it to the // corresponding Python object. for (int i = 0; i < sipCpp -> size(); ++i) { Type *t = sipCpp -> at(i); PyObject *tobj; if ((tobj = sipConvertFromInstance(t, sipClass_Type, sipTransferObj)) == NULL) { // There was an error so garbage collect the Python list. Py_DECREF(l); return NULL; } PyList_SET_ITEM(l, i, tobj); } // Return the Python list. return l; %End } Using this we can use, for example, QList<QObject *> throughout the module's specification files (and in any module that imports this one). The generated code will automatically map this to and from a Python list of QObject instances when appropriate. 7.27 %MethodCode%MethodCode code %End This directive is used as part of the specification of a global function, class method, operator, constructor or destructor to specify handwritten code that replaces the normally generated call to the function being wrapped. It is usually used to handle argument types and results that SIP cannot deal with automatically. Normally the specified code is embedded in-line after the function's arguments have been successfully converted from Python objects to their C or C++ equivalents. In this case the specified code must not include any return statements. However if the NoArgParser annotation has been used then the specified code is also responsible for parsing the arguments. No other code is generated by SIP and the specified code must include a return statement. In the context of a destructor the specified code is embedded in-line in the Python type's deallocation function. Unlike other contexts it supplements rather than replaces the normally generated code, so it must not include code to return the C structure or C++ class instance to the heap. The code is only called if ownership of the structure or class is with Python. The specified code must also handle the Python Global Interpreter Lock (GIL). If compatibility with SIP v3.x is required then the GIL must be released immediately before the C++ call and reacquired immediately afterwards as shown in this example fragment: Py_BEGIN_ALLOW_THREADS sipCpp -> foo(); Py_END_ALLOW_THREADS If compatibility with SIP v3.x is not required then this is optional but should be done if the C++ function might block the current thread or take a significant amount of time to execute. (See The Python Global Interpreter Lock and the ReleaseGIL and HoldGIL annotations.) If the NoArgParser annotation has not been used then the following variables are made available to the handwritten code:
If the NoArgParser annotation has been used then only the following variables are made available to the handwritten code:
The following is a complete example: class Klass { public: virtual int foo(SIP_PYTUPLE); %MethodCode // The C++ API takes a 2 element array of integers but passing a // two element tuple is more Pythonic. int iarr[2]; if (PyArg_ParseTuple(a0, "ii", &iarr[0], &iarr[1])) { Py_BEGIN_ALLOW_THREADS sipRes = sipSelfWasArg ? sipCpp -> Klass::foo(iarr) : sipCpp -> foo(iarr); Py_END_ALLOW_THREADS } else { // PyArg_ParseTuple() will have raised the exception. sipIsErr = 1; } %End }; As the example is a virtual method [7], note the use of sipSelfWasArg to determine exactly which implementation of foo() to call. If a method is in the protected section of a C++ class then the call should instead be: sipRes = sipCpp -> sipProtectVirt_foo(sipSelfWasArg, iarr); If a method is in the protected section of a C++ class but is not virtual then the call should instead be: sipRes = sipCpp -> sipProtect_foo(iarr);
7.28 %Module%Module name [version] This directive is used to identify that the library being wrapped is a C++ library and to define the name of the module and it's optional version number. The name may contain periods to specify that the module is part of a Python package. The optional version number is useful if you (or others) might create other modules that build on this module, i.e. if another module might %Import this module. Under the covers, a module exports an API that is used by modules that %Import it and the API is given a version number. A module built on that module knows the version number of the API that it is expecting. If, when the modules are imported at run-time, the version numbers do not match then a Python exception is raised. The dependent module must then be re-built using the correct specification files for the base module. The version number should be incremented whenever a module is changed. Some changes don't affect the exported API, but it is good practice to change the version number anyway. For example: %Module qt 5 7.29 %ModuleCode%ModuleCode code %End This directive is used to specify handwritten code, typically the implementations of utility functions, that can be called by other handwritten code in the module. For example: %ModuleCode // Print an object on stderr for debugging purposes. void dump_object(PyObject *o) { PyObject_Print(o, stderr, 0); fprintf(stderr, "\n"); } %End See also %ExportedHeaderCode and %ModuleHeaderCode. 7.30 %ModuleHeaderCode%ModuleHeaderCode code %End This directive is used to specify handwritten code, typically the declarations of utility functions, that is placed in a header file that is included by all generated code for the same module. For example: %ModuleHeaderCode void dump_object(PyObject *o); %End See also %ExportedHeaderCode and %ModuleCode. 7.31 %OptionalInclude%OptionalInclude filename This directive is identical to the %Include directive except that SIP silently continues processing if filename could not be opened. For example: %OptionalInclude license.sip 7.32 %PickleCode%PickleCode code %End This directive is used to specify handwritten code to pickle a C structure or C++ class instance. The following variables are made available to the handwritten code:
For example: class Point { Point(int x, y); int x() const; int y() const; %PickleCode sipRes = Py_BuildValue("ii", sipCpp->x(), sipCpp->y()); %End } Note that SIP works around the Python limitation that prevents nested types being pickled. Both named and unnamed enums can be pickled automatically without providing any handwritten code. 7.33 %Platforms%Platforms {name name ...} This directive is used to declare a set of platforms. Platforms (along with %Feature and %Timeline) are used by the %If directive to control whether or not parts of a specification are processed or ignored. Platforms are mutually exclusive - only one platform can be enabled at a time. By default all platforms are disabled. The SIP -t command line option is used to enable a platform. For example: %Platforms {WIN32_PLATFORM POSIX_PLATFORM MACOS_PLATFORM} %If (WIN32_PLATFORM) void undocumented(); %End %If (POSIX_PLATFORM) void documented(); %End 7.34 %PostInitialisationCode%PostInitialisationCode code %End This directive is used to specify handwritten code that is embedded in-line at the very end of the generated module initialisation code. The following variables are made available to the handwritten code:
For example: %PostInitialisationCode // The code will be executed when the module is first imported and // after all other initialisation has been completed. %End 7.35 %PreInitialisationCode%PreInitialisationCode code %End This directive is used to specify handwritten code that is embedded in-line at the very start of the generated module initialisation code. For example: %PreInitialisationCode // The code will be executed when the module is first imported and // before other initialisation has been completed. %End 7.36 %RaiseCode%RaiseCode code %End This directive is used as part of the definition of an exception using the %Exception directive to specify handwritten code that raises a Python exception when a C++ exception has been caught. The code is embedded in-line as the body of a C++ catch () clause. The specified code must handle the Python Global Interpreter Lock (GIL) if necessary. The GIL must be acquired before any calls to the Python API and released after the last call as shown in this example fragment: SIP_BLOCK_THREADS PyErr_SetNone(PyErr_Exception); SIP_UNBLOCK_THREADS Finally, the specified code must not include any return statements. The following variable is made available to the handwritten code:
See the %Exception directive for an example. 7.37 %SetCode%SetCode code %End This directive is used after the declaration of a C++ class variable or C structure member to specify handwritten code to convert it from a Python object. It is usually used to handle types that SIP cannot deal with automatically. The following variables are made available to the handwritten code:
See the %GetCode directive for an example. 7.38 %SIPOptionsThis directive sets one or more options that controls different aspects of SIP's behaviour. In this version all the available options are provided specifically to support PyQt and so are not documented. 7.39 %Timeline%Timeline {name name ...} This directive is used to declare a set of versions released over a period of time. Versions (along with %Feature and %Platforms) are used by the %If directive to control whether or not parts of a specification are processed or ignored. Versions are mutually exclusive - only one version can be enabled at a time. By default all versions are disabled. The SIP -t command line option is used to enable a version. For example: %Timeline {V1_0 V1_1 V2_0 V3_0} %If (V1_0 - V2_0) void foo(); %End %If (V2_0 -) void foo(int = 0); %End %Timeline can be used any number of times in a module to allow multiple libraries to be wrapped in the same module. 7.40 %TypeCode%TypeCode code %End This directive is used as part of the specification of a C structure or a C++ class to specify handwritten code, typically the implementations of utility functions, that can be called by other handwritten code in the structure or class. For example: class Klass { %TypeCode // Print an instance on stderr for debugging purposes. static void dump_klass(const Klass *k) { fprintf(stderr,"Klass %s at %p\n", k -> name(), k); } %End // The rest of the class specification. }; Because the scope of the code is normally within the generated file that implements the type, any utility functions would normally be declared static. However a naming convention should still be adopted to prevent clashes of function names within a module in case the SIP -j command line option is used. 7.41 %TypeHeaderCode%TypeHeaderCode code %End This directive is used to specify handwritten code that defines the interface to a C or C++ type being wrapped, either a structure, a class, or a template. It is used within a class definition or a %MappedType directive. Normally code will be a pre-processor #include statement. For example: // Wrap the Klass class. class Klass { %TypeHeaderCode #include <klass.h> %End // The rest of the class specification. }; 7.42 %UnitCode%UnitCode code %End This directive is used to specify handwritten code that it included at the very start of a generated compilation unit (ie. C or C++ source file). It is typically used to #include a C++ precompiled header file. 7.43 %VirtualCatcherCode%VirtualCatcherCode code %End For most classes there are corresponding generated derived classes that contain reimplementations of the class's virtual methods. These methods (which SIP calls catchers) determine if there is a corresponding Python reimplementation and call it if so. If there is no Python reimplementation then the method in the original class is called instead. This directive is used to specify handwritten code that replaces the normally generated call to the Python reimplementation and the handling of any returned results. It is usually used to handle argument types and results that SIP cannot deal with automatically. This directive can also be used in the context of a class destructor to specify handwritten code that is embedded in-line in the internal derived class's destructor. In the context of a method the Python Global Interpreter Lock (GIL) is automatically acquired before the specified code is executed and automatically released afterwards. In the context of a destructor the specified code must handle the GIL. The GIL must be acquired before any calls to the Python API and released after the last call as shown in this example fragment: SIP_BLOCK_THREADS Py_DECREF(obj); SIP_UNBLOCK_THREADS The following variables are made available to the handwritten code in the context of a method:
No variables are made available in the context of a destructor. For example: class Klass { public: virtual int foo(SIP_PYTUPLE) [int (int *)]; %MethodCode // The C++ API takes a 2 element array of integers but passing a // two element tuple is more Pythonic. int iarr[2]; if (PyArg_ParseTuple(a0, "ii", &iarr[0], &iarr[1])) { Py_BEGIN_ALLOW_THREADS sipRes = sipCpp -> Klass::foo(iarr); Py_END_ALLOW_THREADS } else { // PyArg_ParseTuple() will have raised the exception. sipIsErr = 1; } %End %VirtualCatcherCode // Convert the 2 element array of integers to the two element // tuple. PyObject *result; result = sipCallMethod(&sipIsErr, sipMethod, "ii", a0[0], a0[1]); if (result != NULL) { // Convert the result to the C++ type. sipParseResult(&sipIsErr, sipMethod, result, "i", &sipRes); Py_DECREF(result); } %End }; 8 SIP AnnotationsIn this section we describe each of the annotations that can be used in specification files. Annotations can either be argument annotations, class annotations, mapped type annotations, enum annotations, exception annotations, function annotations, license annotations, typedef annotations or variable annotations depending on the context in which they can be used. Annotations are placed between forward slashes (/). Multiple annotations are comma separated within the slashes. Annotations have a type and, possibly, a value. The type determines the format of the value. The name of an annotation and its value are separated by =. Annotations can have one of the following types:
The following example shows argument and function annotations: void exec(QWidget * /Transfer/) /ReleaseGIL, PyName=call_exec/; Note that the current version of SIP does not complain about unknown annotations, or annotations used out of their correct context. 8.1 Argument Annotations8.1.1 AllowNoneThis boolean annotation specifies that the value of the corresponding argument (which should be either SIP_PYCALLABLE, SIP_PYDICT, SIP_PYLIST, SIP_PYSLICE, SIP_PYTUPLE or SIP_PYTYPE) may be None. 8.1.2 ArrayThis boolean annotation specifies that the corresponding argument (which should be either char * or unsigned char *) refers to an array rather than a '\0' terminated string. There must be a corresponding argument with the ArraySize annotation specified. The annotation may only be specified once in a list of arguments. 8.1.3 ArraySizeThis boolean annotation specifies that the corresponding argument (which should be either short, unsigned short, int, unsigned, long or unsigned long) refers to the size of an array. There must be a corresponding argument with the Array annotation specified. The annotation may only be specified once in a list of arguments. 8.1.4 ConstrainedPython will automatically convert between certain compatible types. For example, if a floating pointer number is expected and an integer supplied, then the integer will be converted appropriately. This can cause problems when wrapping C or C++ functions with similar signatures. For example: // The wrapper for this function will also accept an integer argument // which Python will automatically convert to a floating point number. void foo(double); // The wrapper for this function will never get used. void foo(int); This boolean annotation specifies that the corresponding argument (which should be either bool, int, float, double, enum or a wrapped class) must match the type without any automatic conversions. In the context of a wrapped class the invocation of any %ConvertToTypeCode is suppressed. The following example gets around the above problem: // The wrapper for this function will only accept floating point numbers. void foo(double /Constrained/); // The wrapper for this function will be used for anything that Python can // convert to an integer, except for floating point numbers. void foo(int); 8.1.5 GetWrapperThis boolean annotation is only ever used in conjunction with handwritten code specified with the %MethodCode directive. It causes an extra variable to be generated for the corresponding argument (which should be a wrapped C structure or C++ class instance) which is a pointer to the Python object that wraps the argument. See the %MethodCode directive for more detail. 8.1.6 InThis boolean annotation is used to specify that the corresponding argument (which should be a pointer type) is used to pass a value to the function. For pointers to wrapped C structures or C++ class instances, char * and unsigned char * then this annotation is assumed unless the Out annotation is specified. For pointers to other types then this annotation must be explicitly specified if required. The argument will be dereferenced to obtain the actual value. 8.1.7 OutThis boolean annotation is used to specify that the corresponding argument (which should be a pointer type) is used by the function to return a value as an element of a tuple. For pointers to wrapped C structures or C++ class instances, char * and unsigned char * then this annotation must be explicitly specified if required. For pointers to other types then this annotation is assumed unless the In annotation is specified. 8.1.8 ResultSizeThis boolean annotation is used with functions or methods that return a void * or const void *. It identifies an argument that defines the size of the block of memory whose address is being returned. This allows the sip.voidptr object that wraps the address to support the Python buffer protocol and allows the memory to be read and updated when wrapped by the Python buffer() builtin. 8.1.9 SingleShotThis boolean annotation is used only with arguments of type SIP_RXOBJ_CON to specify that the signal connected to the slot will only ever be emitted once. This prevents a certain class of memory leaks. 8.1.10 TransferThis boolean annotation is used to specify that ownership of the corresponding argument (which should be a wrapped C structure or C++ class instance) is transferred from Python to C++. In addition, if the argument is of a class method, then it is associated with the class instance with regard to the cyclic garbage collector. Note that this can also be used as a function annotation. See Ownership of Objects for more detail. 8.1.11 TransferBackThis boolean annotation is used to specify that ownership of the corresponding argument (which should be a wrapped C structure or C++ class instance) is transferred back to Python from C++. In addition, any association of the argument with regard to the cyclic garbage collector with another instance is removed. Note that this can also be used as a function annotation. See Ownership of Objects for more detail. 8.1.12 TransferThisThis boolean annotation is only used in C++ constructors or methods. In the context of a constructor or factory method it specifies that ownership of the instance being created is transferred from Python to C++ if the corresponding argument (which should be a wrapped C structure or C++ class instance) is not None. In addition, the newly created instance is associated with the argument with regard to the cyclic garbage collector. In the context of a non-factory method it specifies that ownership of this is transferred from Python to C++ if the corresponding argument is not None. If it is None then ownership is transferred to Python. The annotation may be used more that once, in which case ownership is transferred to last instance that is not None. Note that this can also be used as a function annotation. See Ownership of Objects for more detail. 8.2 Class Annotations8.2.1 AbstractThis boolean annotation is used to specify that the class has additional pure virtual methods that have not been specified and so it cannot be instantiated or sub-classed from Python. 8.2.2 DelayDtorThis boolean annotation is used to specify that the class's destructor should not be called until the Python interpreter exits. It would normally only be applied to singleton classes. When the Python interpreter exits the order in which any wrapped instances are garbage collected is unpredictable. However, the underlying C or C++ instances may need to be destroyed in a certain order. If this annotation is specified then when the wrapped instance is garbage collected the C or C++ instance is not destroyed but instead added to a list of delayed instances. When the interpreter exits then the function sipDelayedDtors is called with the list of delayed instances. sipDelayedDtors can then choose to call (or ignore) the destructors in any desired order. The sipDelayedDtors function must be specified using the %ModuleCode directive. It's signature is as follows: static void sipDelayedDtors(const sipDelayedDtor *dd_list); dd_list is the linked list of delayed instances. The following fields are defined.
Note that the above applies only to C and C++ instances that are owned by Python. 8.2.3 DeprecatedThis boolean annotation is used to specify that the class is deprecated. It is the equivalent of annotating all the class's constructors, function and methods as being deprecated. Note that this can also be used as a function annotation. 8.2.4 ExternalThis boolean annotation is used to specify that the class is defined in another module. Declarations of external classes are private to the module in which they appear. 8.2.5 NoDefaultCtorsThis boolean annotation is used to suppress the automatic generation of default constructors for the class. 8.2.6 PyNameThis name annotation specifies an alternative name for the class being wrapped which is used when it is referred to from Python. It is required when a class name is the same as a Python keyword. It may also be used to avoid name clashes with other objects (e.g. enums, exceptions, functions) that have the same name in the same C++ scope. 8.3 Mapped Type Annotations8.3.1 NoReleaseThis boolean annotation is used to specify that the mapped type does not support the sipReleaseMappedType() function. Any %ConvertToTypeCode should not create temporary instances of the mapped type, i.e. it should not return SIP_TEMPORARY. 8.4 Enum Annotations8.4.1 PyNameThis name annotation specifies an alternative name for the enum or enum member being wrapped which is used when it is referred to from Python. It is required when an enum or enum member name is the same as a Python keyword. It may also be used to avoid name clashes with other objects (e.g. classes, exceptions, functions) that have the same name in the same C++ scope. 8.5 Exception Annotations8.5.1 PyNameThis name annotation specifies an alternative name for the exception being defined which is used when it is referred to from Python. It is required when an exception name is the same as a Python keyword. It may also be used to avoid name clashes with other objects (e.g. classes, enums, functions) that have the same name. 8.6 Function Annotations8.6.1 AutoGenThis optional name annotation is used with class methods to specify that the method be automatically included in all sub-classes. The value is the name of a feature (specified using the %Feature directive) which must be enabled for the method to be generated. 8.6.2 DefaultThis boolean annotation is only used with C++ constructors. Sometimes SIP needs to create a class instance. By default it uses a constructor with no compulsory arguments if one is specified. (SIP will automatically generate a constructor with no arguments if no constructors are specified.) This annotation is used to explicitly specify which constructor to use. Zero is passed as the value of any arguments to the constructor. 8.6.3 DeprecatedThis boolean annotation is used to specify that the constructor or function is deprecated. A deprecation warning is issued whenever the constructor or function is called. Note that this can also be used as a class annotation. 8.6.4 FactoryThis boolean annotation specifies that the value returned by the function (which should be a wrapped C structure or C++ class instance) is a newly created instance and is owned by Python. See Ownership of Objects for more detail. 8.6.5 HoldGILThis boolean annotation specifies that the Python Global Interpreter Lock (GIL) is not released before the call to the underlying C or C++ function. See The Python Global Interpreter Lock and the ReleaseGIL annotation. 8.6.6 NewThreadThis boolean annotation specifies that the function will create a new thread. 8.6.7 NoArgParserThis boolean annotation is used with global functions to specify that the supplied %MethodCode will handle the parsing of the arguments. 8.6.8 NoDerivedThis boolean annotation is only used with C++ constructors. In many cases SIP generates a derived class for each class being wrapped (see Generated Derived Classes). This derived class contains constructors with the same C++ signatures as the class being wrapped. Sometimes you may want to define a Python constructor that has no corresponding C++ constructor. This annotation is used to suppress the generation of the constructor in the derived class. 8.6.9 NumericThis boolean annotation specifies that the operator should be interpreted as a numeric operator rather than a sequence operator. Python uses the + operator for adding numbers and concatanating sequences, and the * operator for multiplying numbers and repeating sequences. SIP tries to work out which is meant by looking at other operators that have been defined for the type. If it finds either -, -=, /, /=, % or %= defined then it assumes that +, +=, * and *= should be numeric operators. Otherwise, if it finds either [], __getitem__(), __setitem__() or __delitem__() defined then it assumes that they should be sequence operators. This annotation is used to force SIP to treat the operator as numeric. 8.6.10 PostHookThis name annotation is used to specify the name of a Python builtin that is called immediately after the call to the underlying C or C++ function or any handwritten code. The builtin is not called if an error occurred. It is primarily used to integrate with debuggers. 8.6.11 PreHookThis name annotation is used to specify the name of a Python builtin that is called immediately after the function's arguments have been successfully parsed and before the call to the underlying C or C++ function or any handwritten code. It is primarily used to integrate with debuggers. 8.6.12 PyNameThis name annotation specifies an alternative name for the function being wrapped which is used when it is referred to from Python. It is required when a function or method name is the same as a Python keyword. It may also be used to avoid name clashes with other objects (e.g. classes, enums, exceptions) that have the same name in the same C++ scope. 8.6.13 ReleaseGILThis boolean annotation specifies that the Python Global Interpreter Lock (GIL) is released before the call to the underlying C or C++ function and reacquired afterwards. It should be used for functions that might block or take a significant amount of time to execute. See The Python Global Interpreter Lock and the HoldGIL annotation. 8.6.14 TransferThis boolean annotation specifies that ownership of the value returned by the function (which should be a wrapped C structure or C++ class instance) is transferred to C++. It is only used in the context of a class constructor or a method. In the case of methods returned values (unless they are new references to already wrapped values) are normally owned by C++ anyway. However, in addition, an association between the returned value and the instance containing the method is created with regard to the cyclic garbage collector. Note that this can also be used as an argument annotation. See Ownership of Objects for more detail. 8.6.15 TransferBackThis boolean annotation specifies that ownership of the value returned by the function (which should be a wrapped C structure or C++ class instance) is transferred back to Python from C++. Normally returned values (unless they are new references to already wrapped values) are owned by C++. In addition, any association of the returned value with regard to the cyclic garbage collector with another instance is removed. Note that this can also be used as an argument annotation. See Ownership of Objects for more detail. 8.6.16 TransferThisThis boolean annotation specifies that ownership of this is transferred from Python to C++. Note that this can also be used as an argument annotation. See Ownership of Objects for more detail. 8.7 License Annotations8.7.1 LicenseeThis optional string annotation specifies the license's licensee. No restrictions are placed on the contents of the string. See the %License directive. 8.7.2 SignatureThis optional string annotation specifies the license's signature. No restrictions are placed on the contents of the string. See the %License directive. 8.7.3 TimestampThis optional string annotation specifies the license's timestamp. No restrictions are placed on the contents of the string. See the %License directive. 8.7.4 TypeThis string annotation specifies the license's type. No restrictions are placed on the contents of the string. See the %License directive. 8.8 Typedef Annotations8.8.1 NoTypeNameThis boolean annotation specifies that the definition of the type rather than the name of the type being defined should be used in the generated code. Normally a typedef would be defined as follows: typedef bool MyBool; This would result in MyBool being used in the generated code. Specifying the annotation means that bool will be used in the generated code instead. 8.9 Variable Annotations8.9.1 PyNameThis name annotation specifies an alternative name for the variable being wrapped which is used when it is referred to from Python. It is required when a variable name is the same as a Python keyword. It may also be used to avoid name clashes with other objects (e.g. classes, functions) that have the same name in the same C++ scope. 9 SIP API for Handwritten CodeIn this section we describe the API that can be used by handwritten code in specification files. 9.1 SIP_API_MAJOR_NRThis is a C preprocessor symbol that defines the major number of the SIP API. Its value is a number. There is no direct relationship between this and the SIP version number. 9.2 SIP_API_MINOR_NRThis is a C preprocessor symbol that defines the minor number of the SIP API. Its value is a number. There is no direct relationship between this and the SIP version number. 9.3 SIP_BLOCK_THREADSThis is a C preprocessor macro that will make sure the Python Global Interpreter Lock (GIL) is acquired. Python API calls must only be made when the GIL has been acquired. There must be a corresponding SIP_UNBLOCK_THREADS at the same lexical scope. 9.4 SIP_SSIZE_TThis is a C preprocessor macro that is defined as Py_ssize_t for Python v2.5 and later, and as int for earlier versions of Python. It makes it easier to write PEP 353 compliant handwritten code. 9.5 SIP_UNBLOCK_THREADSThis is a C preprocessor macro that will restore the Python Global Interpreter Lock (GIL) to the state it was prior to the corresponding SIP_BLOCK_THREADS. 9.6 SIP_VERSIONThis is a C preprocessor symbol that defines the SIP version number represented as a 3 part hexadecimal number (e.g. v4.0.0 is represented as 0x040000). 9.7 SIP_VERSION_STRThis is a C preprocessor symbol that defines the SIP version number represented as a string. For development snapshots it will start with snapshot-. 9.8 sipBadCatcherResult()
9.9 sipBadLengthForSlice()
9.10 sipBuildResult()
9.11 sipCallMethod()
9.12 sipCanConvertToInstance()
9.13 sipCanConvertToMappedType()
9.14 sipClassName()
9.15 sipConnectRx()
9.16 sipConvertFromConstVoidPtr()
9.17 sipConvertFromConstVoidPtrAndSize()
9.18 sipConvertFromInstance()
9.19 sipConvertFromMappedType()
9.20 sipConvertFromNamedEnum()
9.21 sipConvertFromNewInstance()
9.22 sipConvertFromSequenceIndex()
9.23 sipConvertFromSliceObject()
9.24 sipConvertFromVoidPtr()
9.25 sipConvertFromVoidPtrAndSize()
9.26 sipConvertToCpp()
9.27 sipConvertToInstance()
9.28 sipConvertToMappedType()
9.29 sipConvertToVoidPtr()
9.30 sipDisconnectRx()
9.31 sipEmitSignal()
9.32 sipExportSymbol()
9.33 sipFindClass()
9.34 sipFindMappedType()
9.35 sipFindNamedEnum()
9.36 sipForceConvertToInstance()
9.37 sipForceConvertToMappedType()
9.38 sipFree()
9.39 sipGetSender()
9.40 sipGetWrapper()
9.41 sipImportSymbol()
9.42 sipIntTypeClassMapThis C structure is used with sipMapIntToClass() to define a mapping between integer based RTTI and generated type objects. The structure elements are as follows.
9.43 sipIsSubClassInstance()
9.44 sipLong_AsUnsignedLong()
9.45 sipMalloc()
9.46 sipMapIntToClass()
9.47 sipMapStringToClass()
9.48 sipParseResult()
9.49 sipReleaseInstance()
9.50 sipReleaseMappedType()
9.51 sipStringTypeClassMapThis C structure is used with sipMapStringToClass() to define a mapping between '\0' terminated string based RTTI and generated type objects. The structure elements are as follows.
9.52 sipTransfer()
9.53 sipTransferBack()
9.54 sipTransferBreak()
9.55 sipTransferTo()
9.56 sipWrapperThis is a C structure that represents a Python wrapped instance. It is an extension of the Python PyObject structure and so may be safely cast to PyObject. It includes a member called user which is of type PyObject *. This can be used for any purpose by handwritten code and will automatically be garbage collected at the appropriate time. 9.57 sipWrapper_Check()
9.58 sipWrapperTypeThis is a C structure that represents a SIP generated type object. It is an extension of the Python PyTypeObject structure (which is itself an extension of the Python PyObject structure) and so may be safely cast to PyTypeObject (and PyObject). 9.59 Generated Type ConvertorsThese functions are deprecated from SIP v4.4. SIP generates functions for all types being wrapped (including mapped types defined with the %MappedType directive) that convert a Python object to the C structure or C++ class instance. The name of this convertor is the name of the structure or class prefixed by sipForceConvertTo_.
SIP also generates functions for mapped types that convert a C structure or C++ class instance to a Python object. The name of this convertor is the name of the structure or class prefixed by sipConvertFrom_.
The convertor functions of all imported types are available to handwritten code. 9.60 Generated Type ObjectsSIP generates a type object for each C structure or C++ class being wrapped. These are sipWrapperType structures and are used extensively by the SIP API. These objects are named with the structure or class name prefixed by sipClass_. For example, the type object for class Klass is sipClass_Klass. The type objects of all imported classes are available to handwritten code. 9.61 Generated Named Enum Type ObjectsSIP generates a type object for each named enum being wrapped. These are PyTypeObject structures. (Anonymous enums are wrapped as Python integers.) These objects are named with the fully qualified enum name (i.e. including any enclosing scope) prefixed by sipEnum_. For example, the type object for enum Enum defined in class Klass is sipEnum_Klass_Enum. The type objects of all imported named enums are available to handwritten code. 9.62 Generated Derived ClassesFor most C++ classes being wrapped SIP generates a derived class with the same name prefixed by sip. For example, the derived class for class Klass is sipKlass. If a C++ class doesn't have any virtual or protected methods in it or any of it's super-class hierarchy, or does not emit any Qt signals, then a derived class is not generated. Most of the time handwritten code should ignore the derived classes. The only exception is that handwritten constructor code specified using the %MethodCode directive should call the derived class's constructor (which has the same C++ signature) rather then the wrapped class's constructor. 9.63 Generated Exception ObjectsSIP generates a Python object for each exception defined with the %Exception_ directive. These objects are named with the fully qualified exception name (i.e. including any enclosing scope) prefixed by sipException_. For example, the type object for enum Except defined in class Klass is sipException_Klass_Except. The objects of all imported exceptions are available to handwritten code. 10 Using the SIP API when EmbeddingThe SIP API described in the previous section is intended to be called from handwritten code in SIP generated modules. However it is also often necessary to call it from C or C++ applications that embed the Python interpreter and need to pass C or C++ instances between the application and the interpreter. The API is exported by the SIP module as a sipAPIDef data structure containing a set of function pointers. The data structure is defined in the SIP header file sip.h. The data structure is wrapped as a Python PyCObject object and is referenced by the name _C_API in the SIP module dictionary. Each member of the data structure is a pointer to one of the functions of the SIP API. The name of the member can be derived from the function name by replacing the sip prefix with api and converting each word in the name to lower case and preceding it with an underscore. For example:
Note that the type objects that SIP generates for a wrapped module (see Generated Type Objects, Generated Named Enum Type Objects and Generated Exception Objects) cannot be refered to directly and must be obtained using the sipFindClass(), sipFindMappedType() and sipFindNamedEnum() functions. Of course, the corresponding modules must already have been imported into the interpreter. The following code fragment shows how to get a pointer to the sipAPIDef data structure: #include <sip.h> const sipAPIDef *get_sip_api() { PyObject *sip_module; PyObject *sip_module_dict; PyObject *c_api; /* Import the SIP module. */ sip_module = PyImport_ImportModule("sip"); if (sip_module == NULL) return NULL; /* Get the module's dictionary. */ sip_module_dict = PyModule_GetDict(sip_module); /* Get the "_C_API" attribute. */ c_api = PyDict_GetItemString(sip_module_dict, "_C_API"); if (c_api == NULL) return NULL; /* Sanity check that it is the right type. */ if (!PyCObject_Check(c_api)) return NULL; /* Get the actual pointer from the object. */ return (const sipAPIDef *)PyCObject_AsVoidPtr(c_api); } 11 Using the SIP Module in ApplicationsThe main purpose of the SIP module is to provide functionality common to all SIP generated bindings. It is loaded automatically and most of the time you will completely ignore it. However, it does expose some functionality that can be used by applications.
12 The SIP Build SystemThe purpose of the build system is to make it easy for you to write configuration scripts in Python for your own bindings. The build system takes care of the details of particular combinations of platform and compiler. It supports over 50 different platform/compiler combinations. The build system is implemented as a pure Python module called sipconfig that contains a number of classes and functions. Using this module you can write bespoke configuration scripts (e.g. PyQt's configure.py) or use it with other Python based build systems (e.g. Distutils and SCons). An important feature of SIP is the ability to generate bindings that are built on top of existing bindings. For example, both PyKDE and PyQwt are built on top of PyQt but all three packages are maintained by different developers. To make this easier PyQt includes its own configuration module, pyqtconfig, that contains additional classes intended to be used by the configuration scripts of bindings built on top of PyQt. The SIP build system includes facilities that do a lot of the work of creating these additional configuration modules. 12.1 sipconfig Functions
12.2 sipconfig Classes
13 Building Your Extension with distutilsTo build the example in A Simple C++ Example using distutils, it is sufficient to create a standard setup.py, listing word.sip among the files to build, and hook-up SIP into distutils: from distutils.core import setup, Extension import sipdistutils setup( name = 'word', versione = '1.0', ext_modules=[ Extension("word", ["word.sip", "word.cpp"]), ], cmdclass = {'build_ext': sipdistutils.build_ext} ) As we can see, the above is a normal distutils setup script, with just a special line which is needed so that SIP can see and process word.sip. Then, running setup.py build will build our extension module. 14 Builtin Modules and Custom InterpretersSometimes you want to create a custom Python interpreter with some modules built in to the interpreter itself rather than being dynamically loaded. To do this the module must be created as a static library and linked with a custom stub and the normal Python library. To build the SIP module as a static library you must pass the -k command line option to configure.py. You should then build and install SIP as normal. (Note that, because the module is now a static library, you will not be able to import it.) To build a module you have created for your own library you must modify your own configuration script to pass a non-zero value as the static argument of the __init__() method of the ModuleMakefile class (or any derived class you have created). Normally you would make this configurable using a command line option in the same way that SIP's configure.py handles it. The next stage is to create a custom stub and a Makefile. The SIP distribution contains a directory called custom which contains example stubs and a Python script that will create a correct Makefile. Note that, if your copy of SIP was part of a standard Linux distribution, the custom directory may not be installed on your system. The custom directory contains the following files. They are provided as examples - each needs to be modified according to your particular requirements.
Note that this technique does not restrict how the interpreter can be used. For example, it still allows users to write their own applications that can import your builtin modules. If you want to prevent users from doing that, perhaps to protect a proprietary API, then take a look at the VendorID package. |