[PyQt] PyQt Development Roadmap Published

[Phil Thompson]

On Mon, 20 Oct 2008 23:17:42 +0200, Giovanni Bajo <rasky at develer.com>
wrote:
> On lun, 2008-10-20 at 12:28 +0100, Phil Thompson wrote:
>> I've published a development roadmap for PyQt at
>> http://www.riverbankcomputing.com/software/pyqt/roadmap.
>> 
>> It describes my current thinking - but everything is still up for grabs.
>> It's not intended to capture every planned change - but I do want to
>> identify every incompatible change.
>> 
>> Comments and suggestions welcome.
> 
>  * Thanks for publishing a roadmap. It's very nice to get the community
> involved into the design process.
> 
>  * +1 on the general idea of separating the API changes from the Python
> v3 support. The fact that we can upgrade to Python v3 separately from
> upgrading the API seems a good idea.
> 
>  * Would the v1 API be deprecated? Do you plan to eventually remove it
> sooner or later?

The v1 API will always be available in PyQt4. It may be available in
PyQt5/Qt5, but if it was it probably wouldn't be the default.

I will allow pyqtSetAPIVersion() to explicitly set the v1 API. 

If PyQt4 stays the current version for a few years then there may come a
point where everybody is using v2 and keeps on asking on the mailing list
why it's not the default. We can all have that discussion at the time - it
would be easy to change.

>  * Python connections: I don't see many benefits in it, the only one
> which I value is the error checking. But I don't know if it's worth of
> coming up with a new API. Anyway, you are also keeping the current (C
> ++-ish) API, so it does not really bother me if you add it. I guess
> others might find it useful or nice.

It's a bit like Python indentation, the loudest complaints come from people
who don't use it.

For me personally, it's the verbosity of the current approach that I
dislike the most.

>  * Implicit copying of const&: I think it's mostly a good idea. The bugs
> it causes have bitten every PyQt programmer I met at least once. I think
> the only counter-argument would be for functions returning *large*
> objects as const&, but it's not something that happens in Qt as far as I
> can tell. Would the change also apply to all SIP extensions? Or would
> there be an annotation to choose the behaviour? I'm not sure it's fully
> backward compatible, as far as SIP is concerned.

You're right. I do plan it to be optional as far as SIP is concerned. I
haven't yet decided on the level of granularity. I'll probably start with a
global flag.

>  * Automatic Type Conversion: yes, this is great :)
> 
>  * QDataStream and Arbitrary Python Objects: I don't use QDataStream
> much and I guess I could have used pickle myself with it, but having a
> specific API might be handy, yes.
> 
>  * Qt Model Wrappers for Python Types: I don't like Qt Model/View
> classes much, so I pass on this :)
> 
>  * Resolve Name Clashes: I was discussing this with Mark Summerfield
> off-list. IMO, fixing the clashes with the underscore is a perfect
> solution, and it's the only (minor) nit with using the star-import with
> PyQt. I hope this applies as a general rules, in case Qt introduces new
> names conflicting with Python builtins. I know that Mark had a different
> view -- he preferred the star-import to only bring names that begin with
> "Q" into the namespace. I don't agree, but I'll let him bring up his
> argument better than I could do :)
> 
>  * Removal of Non-Pythonic Classes: the only thing that bothers me is
> QByteArray. QByteArray can be used for handling large buffers of memory,
> and having to copy them around seems like a suboptimal solution.
> Moreover, QByteArray is mutable: what are you going to map it to? The
> new bytearray type in Python 2.6? It would be great if it was possible
> to avoid the memory copy. Since QByteArray is copy-on-write, maybe
> something can be done (like: increase the internal reference, then get
> the raw pointer and built a bytearray around it. Or something like
> that).

I have similar concerns about QByteArray, although I don't think I've ever
actually used it myself.

>  * Implementation of __hash__: Yes, I think this is also necessary.
> There have been a few examples posted to the mailing list.
> 
>  * Documentation Improvements: I don't use the PyQt documentation,
> mainly because it's in raw HTML format and I find myself much more
> comfortable with Assistant. I guess I could import it into Assistant
> somehow, but I haven't bothered looking, since I find the C++
> documentation more than enough. So one suggestion here is to ship the
> documentation in the Assistant format (or even better with a binary copy
> of the assistant renamed pyassistant, already bound to the correct html
> files).
> 
> Thanks again for discussing this with us!

Phil