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.

6.	Add support for references and pointers in function arguments - assume
they are being used to return values (or have In, Out and InOut option flags).

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.

12.	Look at the memory leak in virtual handler code, eg. when a virtual
method returns a QString (not a pointer to a QString).  Should be able to avoid
the leak if we take advantage of the class having a copy ctor.

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

14.	Look at how the result of a Python virtual method is handled if it is
the wrong type - particularly if it is None/NULL and shouldn't be.

15.	Add %MemberCall as an alternative to %MemberCode which (unlike the
latter) generates the argument parsing and result handling code but not the
code that actually calls the method.  This allows the user to specify the
arguments/result in terms of what they want from Python rather than what they
get from C++.  So long as what they want are types that SIP can generate code
for, less handwritten code is required.

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

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.

23.	Look at supporting properties as introduced in Python 2.2.

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).
