On Mon, 06 Oct 2008 20:52:50 +0200, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > On 10/6/2008 8:42 PM, Phil Thompson wrote: >> On Mon, 06 Oct 2008 19:42:26 +0200, Giovanni Bajo <[EMAIL PROTECTED]> >> 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'm quite happy to consider that if it can be done without confusing the >> hell out of everyone. >> >> The only way to allow two incompatible versions of PyQt to sit in the >> same >> Python installation (that would be a requirement) would be to have the >> new >> version be PyQt5. >> >> Is that a good idea? > > Looks like it, until Qt5 is out ;) > > Multi-version installs are possible without changing the package name, > in the same way that .egg/setuputils does: using a .pth file to select a > given version at startup time (site.py). > > wxPython has been doing it for ages to eg. switch between ANSI and > Unicode version, or keeping several version in parallel and let the user > change the current one. You would need to be able to run PyQt4 and PyQt5 applications at the same time. Phil _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
