1.	Make the parser aware of Python keywords so they can't be used as
member function names.

2.	Tighten up the recognition of function signatures that involve char,
unsigned char etc.

4.	Add support for template classes.  I don't think a template class can
ever have an object created in Python (or a Python sub-classed from one).  It
would only be useful if the C++ library contained sub-classes of it (see
QwPositionedSprite and QwSprite).

5.	Allow handwritten code for static class variables (like
KTMainWindow.memberList).  The problem is intercepting references to it
(__getattr__ and __setattr__ aren't good enough) - probably extending the
lazy function mechanism.

8.	Add support for handwritten code for signals (eg.
QNetworkProtocol::newChildren).

11.	Consider changing the way default arguments that are function calls are
handled.  At the moment the function is always called and the result discarded
if it is not needed.  It should really only be called if the result is really
needed.

13.	Look at ways of making a C++ dtor callable from Python.

17.	At least implement simple cast operators (ie. cast to class, cast to
int), and use in QKeySequence.  (See 29)

18.	Implement the C++ feature of automatically calling simple ctors to
transparently convert between types for function parameters.  For example, a
function takes a parameter of type QKeySequence, but is passed an int, but
there is a QKeySequence ctor that takes a single int - so call it
automatically.  This just needs extra code generated for the CanConvertTo and
ConvertTo functions.  This will only work where the destination type is a
class.  Note that we will end up doing lots of checks in the CanConvertTo
function and repeating them in the ConvertToFunction.  It would be better if
the CanConvertTo function could return some information (even the results of
the conversion of simple types like ints) to be re-used by ConvertTo - but make
sure default arguments are handled correctly.  We could implement it for base
types as well (if the source type implemented an appropriate cast operator) but
the way of doing argument parsing would have to change completely - if
sipParseArgs was trying to convert an argument to an int it would have to have
a table of all types that could be converted to an int (messy and slow?).

19.	Consider changing sipConvertToCpp() to take a PyObject* (rather than a
sipThisType*) and do a check and conversion internally.

20.	Fix potential memory leak in sipForceConvertTo_*() for mapped types.

21.	Add support for const void* (ie. add the extra casts where needed).

22.	Consider adding support for methods that take keyword arguments.  Do it
by allowing a function parameter to have a name (this becomes the keyword) and
extend sipParseArgs() to take an options dictionary and list of keywords.

24.	Need some way of implementing new Qt properties, or at least fiddle the
implementation of QSqlPropertyMap to allow new customer editor widgets to be
implemented in Python.

25.	Add support for specifying docstrings for generated methods.

26.	Fully implement QObject.disconnect().

27.	Look at adding QObject.Q_OBJECT() that will create the moc generated
methods dynamically (maybe just the tr() functions).

28.	Consider creating a copy of a const reference when wrapping it in order
to enforce const in Python.  Or add a flag to the wrapper which says it is a
const instance.

29.	Support global operators if the first argument is a class.  If the
class is in the current module then add it as if it has been defined as an
operator in that class.  Treat class casts in the same way - actually
implementing them as ctors.  Allow modules to define global operators, and
class casts, for classes defined in other modules.  The generated code must be
exported and called when ctors and operators fail because the signature isn't
recognised.

30.	Allow %TypeHeaderCode to be used in namespaces.  Also make sure such
code is automatically included by sub-namespaces, and apply the same to
classes.
