|
|
|
|
|
RoadmapThis describes the roadmap for the future development of PyQt. Suggestions for further changes are welcome and can be made through the website or using the mailing list. PyQt already wraps pretty much the whole of Qt and the support for new versions of Qt as they are released is a given. Apart from changes needed to keep up with the development of related software (e.g. the release of Python v3) the main thrust of future development will be aimed at making the development of PyQt applications even more of a pleasure than it already is. The roadmap has been split into the following sections. Note that no information is provided about the priorities of the different developments. History12th June 2009
26th May 2009
Backwards Compatible ChangesBackwards compatibility is extremely important to PyQt. However, in some cases a proposed change may not be 100% compatible but it is felt that the number of applications affected by such a change will be very small and be outweighed by the benefit to the majority of applications. If you disagree about the impact of such a change then please let us know. The following developments are planned. Automatic Type ConversionsC++ will automatically invoke a non-explicit constructor, if possible, to convert a value to the required type. This facility will be added to PyQt. QDataStream and Arbitrary Python ObjectsQDataStream will be enhanced so that it can handle any Python object using the pickle protocol automatically as required. There will be a readPyObject() method that will return a Python object of the correct type. There will be a writePyObject() method that will accept a Python object of any type. Qt Model Wrappers for Python TypesIt is planned to include QAbstractItemModel subclasses that will handle standard Python types, e.g. dict. It isn't clear how far this can be taken, and so initial implementations are likely to be experimental. Incompatible ChangesSome planned developments will mean that the behaviour of PyQt will not be backwards compatible. All such changes will be made optional and must be explicitly enabled by an application before any PyQt module is imported. For convenience the different incompatible changes will be grouped together and collectively refered to as version 2. The following code illustrates the anticipated usage:
import sip
sip.setapi('PyQt4', 2)
from PyQt4 import QtCore, QtGui
The call to sip.setapi() will only be required once, and not in every module that imports a PyQt module. There will also be a corresponding sip.getapi() function. The following incompatible changes are planned. Resolve Name ClashesThe following module level objects have names which are also the names of Python builtins. This means that using the from module import * style of import statement can produce unexpected results.
They will be renamed by having an underscore appended. Removal of Non-Pythonic ClassesSeveral Qt classes correspond closely to certain standard Python types. QString and Python's unicode object is perhaps the most obvious example. Where there is a significant overlap then the Qt classes will be removed and will be automatically converted to and from the corresponding Python type. The following Qt classes will be removed.
Implementation of __hash__PyQt only implements __hash__ for Qt classes if Qt implements qHash() for the class. The Qt API will be reviewed to identify other classes where an implementation of __hash__ would be appropriate. So far the following classes have been identified.
Documentation ImprovementsThe current PyQt documentation consists of a reference guide and a detailed class reference describing each API call. The class reference is created by scraping the Qt HTML documentation and applying some simple transformations. The result is very useful, but by no means perfect. The main problems are that lots of the Qt background documentation is missing, and all the examples are in C++ rather than Python. Since the tools used to create the documentation were developed, the Qt documentation has been made available as XML and the examples explicitly identified as such. This will make it much easier to produce more complete, maintainable and Python-specific PyQt documentation. The new documentation tools will be designed to support multiple backend formats so that, for example, both Qt-style documentation and Python-style documentation (using Sphinx) could, in theory, be produced. Making a Suggestion |
Recent newsDownloads |
