[PyQt] PyQt Development Roadmap Published

[Giovanni Bajo]

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?

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

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

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

 * 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!
-- 
Giovanni Bajo
Develer S.r.l.
http://www.develer.com