The "signature" attribute of the "add-function" usually get C++ types for the
function arguments, example:

<add-function signature="foo(int, ClassA*)"...>

with "ClassA" being a wrapped class declared in some type system file. The
types declared are recognized by the generator and are used to produce code
for:

* type checking
* type conversion
* the method overload decisor

When a Python object is an argument this form is used:

<add-function signature="foo(PyObject*)" ...>

PyObject* can be anything from Python. Normally it works fine, but there are
cases when a specific Python object provided by the binding developer must be
used.

Practical example: PySide.QtCore.Signal, provided by libpyside.

This will not work:

<add-function signature="foo(PySide.QtCore.Signal)" ...>

neither this (using the C++ name "PySide::SignalInstanceData"):

<add-function signature="foo(PySide::SignalInstanceData*)" ...>

So the code injection for this new method signature will have to deal with type
checking (see if the provided PyObject is PySide::SignalInstanceData) and
emitting the exception if needed (remember that the generator can do this with
the types he already knows), and also writing a proper exception message.

For the last item an example where the first argument is expected to be
PySide.QtCore.Signal, but the current limitations allow only for PyObject to be
used in the signature:

TypeError: 'PySide.QtCore.QState.addTransition' called with wrong argument
types:
  PySide.QtCore.QState.addTransition(str, PySide.QtCore.QState)
Supported signatures:
  PySide.QtCore.QState.addTransition(PyObject, PySide.QtCore.QAbstractState)
  ...

A proper supported signature string would be:
Supported signatures:
  PySide.QtCore.QState.addTransition(PySide.QtCore.Signal,
PySide.QtCore.QAbstractState)
  ...