On Mon, 20 Oct 2008 23:17:42 +0200, Giovanni Bajo <[EMAIL PROTECTED]> 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 _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
