[PyQt] PyQt Development Roadmap Published

[Daniel Miller]

> I've published a development roadmap for PyQt at
> http://www.riverbankcomputing.com/software/pyqt/roadmap.

This looks very nice Phil. Thanks for publishing this detailed  
description of what is planned. I think it's very valuable because it  
allows people to give feedback before things are set in stone.

> Comments and suggestions welcome.

Suggestion 1 - The API version should default to the newest version  
and only require an explicit statement to set it back to a previous  
version. Anyone porting an application from an older version of PyQt  
can easily request the previous API version by inserting a statement  
before they import PyQt4 for the first time. Everyone else gets all  
the newest features by default. Maybe you were already planning it  
that way... If so, please ignore this suggestion.

Suggestion 1.5 - I'm not sure how feasible it would be, but it would  
be very handy to allow feature-specific enable/disable mechanism  
similar to Python's from __future__ import ... mechanism for backward- 
incompatible features. Note the subtle difference of disabling a new  
feature rather than enabling a feature that will be standard in the  
future. In the case of PyQt it would allow the user to revert  
behavior of new features piecemeal rather than reverting the entire  
API to a previous version. For example:

import PyQt4

PyQt4.disableFeature("Resolve Name Clashes")
PyQt4.disableFeature("Removal of Non-Pythonic Classes")
PyQt4.disableFeature("Implementation of __hash__")

This would support gradual integration as an application is improved  
to handle new features of PyQt4. The disadvantage is that it would  
require multiple statements to make the entire library to conform to  
a previous API version, but I think that is a small price to pay for  
the benefit of allowing specific features to be enabled as they are  
supported. Obviously these switches would need to be documented to  
allow porters to know what they are.


Suggestion 2 - It looks like you're planning to add several new  
classes and/or functions to make PyQt more pythonic (e.g. pyqtSignal,  
pyqtBoundSignal, pyqtSlot, etc.). This is an excellent idea. My  
suggestion is to put these in the PyQt4 namespace. Here's an updated  
version of (part of) the pyqtSignal example:

from PyQt4 import QtCore, Signal

class Foo(QtCore.QObject):

     # This defines a signal called 'closed' that takes no arguments.
     closed = Signal()

     ...


The new pyqtSignal class (or PyQt4.Signal in my example) is specific  
to PyQt and therefore should not be part of the QtCore namespace  
(which is Trolltech's domain).

Finally, just a nitpick, it might be a good idea to use PEP8 style  
naming conventions (i.e. CapWords for classes - see Class Names  
section of PEP8[1]). If you decide to keep pyqtSignal in the QtCore  
package then it should be named PyqtSignal or simply Signal.

~ Daniel


   [1] <http://www.python.org/dev/peps/pep-0008/>