12. Make the parser aware of Python keywords so they can't be used as
member function names.
19. Tighten up the recognition of function signatures that involve char,
unsigned char etc.
20. Implement the transfer of ownership for function results and variables
as well. Also need to consider class variables.
25. 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).
31. 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.
32. Add support for references and pointers in function arguments - assume
they are being used to return values.
33. Consider using ConvertToSubClassCode for QObject so that the correct
Python type for an instance created by Qt can be used. Or use RTTI and let SIP
generate the necessary code automatically. In either case, have to consider
how to deal with sub-classes defined in other modules (need a way of a module
registering sub-classes with the original class).
34. Add support for handwritten code for signals (eg.
35. Fix the hack for private abstract functions. If they are virtual we
probably want them to look for a Python method (even though they are private),
36. Generate code that tests whether bool is implemented properly or is
just an int. In some places treating bools as ints will work - in others they
will cause a signature clash (eg. proxySlot()).
37. 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
38. Look at whether code for += style operators can be automated. Then
look at implementing iterators in PyQt.
41. 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.
42. Look at ways of making a C++ dtor callable from Python.
43. 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.
44. 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.