[PyQt] PyQt Development Roadmap Published

[Phil Thompson]

On Mon, 20 Oct 2008 10:46:50 -0400, Daniel Miller <daniel at keystonewood.com>
wrote:
>> 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.

I'm not going to do this because it would break backwards compatibility.
People will want to upgrade to the latest PyQt for bug fixes and they
shouldn't be required to change their application at the same time.

> 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 is similar to how I expect it to be implemented (apart from it will be
enableFeature() because of the backwards compatibility issue. Something
like...

def pyqtSetAPIVersion(v):
    import sip

    if v == 2:
        sip.set_object_api('PyQt4.QtCore.QString', 2)
        sip.set_object_api('PyQt4.QtCore.QVariant', 2)
        # etc.
    else if v == 3:
        # Who knows...

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

There are already non-Qt things in the QtCore namespace - but they are all
prefixed with 'pyqt'. To put them in the PyQt namespace would still require
them to be implemented in QtCore (or a new hidden module) and explicitly
imported by __init__.py.

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

I won't go on a rant about the deficiencies of PEP8 (things should be spelt
according to what they represent, not how they are implemented), however I
think the hobgoblin section is sufficient justification.

Phil