On Mon, Oct 6, 2008 at 7:33 PM, Doug Bell <[EMAIL PROTECTED]> wrote: > Giovanni Bajo wrote: >> On 10/6/2008 7:27 PM, Joshua Kugler wrote: >>> Phil Thompson wrote: >>> >>>> 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. >>> >>> Before you do that, please take into consideration Guido's advice: >>> >>> "Don't change your APIs incompatibly when porting to Py3k." >>> >>> http://www.artima.com/weblogs/viewpost.jsp?thread=227041 >> >> I think the main collision here is that Guido is trying to help people >> porting their applications to Python 3.0, while Phil seems to think that >> it's better to rewrite them. >> >> IMO, PyQt shouldn't force its users to rewrite their code, especially >> *not* tieing this to someone else's schedule (Qt4 release, Python 3 >> release). If an application grows unmaintainable, it will get eventually >> rewritten but only when the programmer thinks so. >> >> Putting incompatible changes into PyQt and then telling people "*now* >> it's time to rewrite" doesn't seem a good path forward to me. >> >> If there's agreement that we need to break backward compatibility on >> PyQt (by changing the way QString or QVariant are mapped), I think it's >> better to do so *independently* from any other changes (eg: Python 3). > > I disagree, for several reasons: > > - Doing the changes separately means maintaining three separate > versions of PyQt at once, taking more of Phil's time and promoting > confusion. > > - Many Linux distros are unlikely to support all three versions at > once. > > - The QString changes are somewhat related to Python 3's unicode > string changes. Both changes would affect the same portions of > application code. > > - I agree that porting an application with both sets of changes is > tougher than doing one change alone, but it's still easier to > thoroughly test my applications once, rather than twice.
My humble opinion: Take some time with the community, collect opinion on all the bad parts of PyQt, and then make a clean break to rewrite PyQt4 for Python 2.6, making use of future features whenever possible. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
