On Tue, 07 Oct 2008 18:06:05 +0200, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > On 10/7/2008 7:07 AM, Phil Thompson wrote: >> On Mon, 6 Oct 2008 21:30:49 -0500, "Arthur Pemberton" <[EMAIL PROTECTED]> >> wrote: >>> 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. >> >> I definitely won't be targeting 2.6 for anything. The idea that people >> will >> move their 2.x code to 2.6, and then move it again to 3.0 is, to me, >> crazy. > > FWIW, it's what every business user of Python I'm in contact with is > going to do. > > I can't see an application with eg. 50K lines of Python code being > rewritten from scratch for Python 3.0 so that it ends up being 20% > slower on 3.0, and you get a couple years of development with no > intermediate releases. > > Instead, migrating any codebase of moderate size to a new 2.x version is > usually quite easy (once all the 3rd party libraries are out of course) > and doesn't take more than a couple weeks altogether. It also has the > immediate benefits of getting the speedup of the new compiler and the > new builtin libraries/functions. So the tradeoff is usually acceptable. > > Once the application is so trivially moved to 2.6, it can be slowly > moved to 3.0 feature by feature, module by module, by the means of > future imports and -3. This will probably take *years* after 3.0 is out > because it won't never be a priority (and by that time, I also hope 3.0 > will be faster). And this is s perfectly fine and within the timelines > that Guido proposes for Python 2.x and 3.x.
I didn't mean to suggest that 2.6 wasn't worth using, only that to move to it *only* as a stepping stone to 3.0 wasn't sensible. Phil _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
