On Fri, 03 Oct 2008 12:42:53 -0700, Glenn Linderman <[EMAIL PROTECTED]> wrote: > On approximately 10/3/2008 8:18 AM, came the following characters from > the keyboard of Phil Thompson: >> On Fri, 3 Oct 2008 17:11:19 +0200, Detlev Offenbach >> <[EMAIL PROTECTED]> wrote: >> >>> Hi, >>> >>> will there be PyQt4 support for Python 3.0 once it goes final? >>> >> >> Not straight away. I will take the opportunity to break backwards >> compatibility (eg. removing QVariant, QString, QChar, QByteArray etc), >> and >> those changes will be made over a period of time. So it may be a while >> before the API is stable enough for anything other than playing. > > While these are excellent goals, and some of the other suggestions have > merit, know that there is interest. > > Probably there are two classes of users; those wanting to port existing > applications, that would want to see "compatibility wrappers" for > existing code to allow a slow migration to the new APIs, and those that > are writing new applications, and would like to bypass all the "old cruft". > > My personal situation is that I have only recently begun writing my > first major PyQt application, using Python 2.5 and PyQt 4. This will > take me "a while" also. Depending on how long our "a while"s are, I > hope to probably release the application using Python 3.0 and the > appropriate PyQt (be it 4 or 5 or whatever). > > Any suggestions you can make regarding how to best approach writing code > to prepare for the eventual PyQt on Python 3.0 would be welcome; and any > timelines that you can provide would be welcome. I am willing to "play > along" to some extent, trying out new versions at least with test > programs, if not the actual application, although I haven't yet > attempted to build PyQt from source, so am dependent on install packages.
When you are maintaining a package that thousands of people use, backwards compatibility is both very important and a complete pain. Therefore, when you get the chance to get rid of the old cruft (aka regrettable design decisions) you take them. Personally I think "compatibility wrappers" are a waste of time and effort. There are times when you really should rewrite your application (and I don't care how big it is). PyQt4 is a complete rewrite of PyQt3, SIP5 will not share any code with SIP4. Major transitions (Qt3 => Qt4, Python2 => Python3) should be considered as opportunities for rewrites. They should not be treated as "how can I get from one to the other with as few changes as possible". Therefore, to answer your specific question, if you need to deploy your application within 6 months (as a minimum) then write for Python2. If you do then don't bother trying to write it with Python3 in mind. By the time you get to the point when you want a Python3 version you will have realised how badly you wrote it in the first place that you will want to rewrite it anyway. On the other hand, if you did write it correctly in the first place (something I've never managed) PyQt4 for Python2 will be maintained for several years - certainly while new versions of Python2 are released. Phil _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
