[PyQt] Re: PyQt4 and Python 3.0

[Giovanni Bajo]

On lun, 2008-10-06 at 20:19 +0100, Phil Thompson wrote:
> On Mon, 06 Oct 2008 21:10:44 +0200, Giovanni Bajo <rasky at develer.com>
> wrote:
> > On 10/6/2008 9:04 PM, Phil Thompson wrote:
> >> On Mon, 06 Oct 2008 20:52:50 +0200, Giovanni Bajo <rasky at develer.com>
> >> wrote:
> >>> On 10/6/2008 8:42 PM, Phil Thompson wrote:
> >>>> On Mon, 06 Oct 2008 19:42:26 +0200, Giovanni Bajo <rasky at develer.com>
> >>>> 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
> >>>>>>> <detlev at die-offenbachs.de> 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.
> > 
> > pkg_resources handles it through require() and a version control string. 
> > require("PyQt4 >= 5.0"). require() activates the correct version at
> > runtime.
> > 
> > Also let's remembers that people distributing applications under Windows 
> > or Mac probably don't have this problem at all, since the package they 
> > distribute includes the correct version of PyQt for each application. 
> > The problems are mainly on Linux which basically forces sharing of 
> > libraries system-wide.
> 
> I'm not going to impose a requirement on an external package.

It would be required only for those who need to run both versions at the
same time. Or you could reinvent the wheel and do the same by hand, by
the means of something like:

import PyQt4
PyQt4.setVersion("5.0")

or:

form PyQt4.v2 import QtCore

"PyQt5" seems confusing to me when/if Qt5 comes out (and I always find
confusing that PyQt4 version number is too similar to Qt version number;
I'd go for something totally different like "PyQt4 version 18").
-- 
Giovanni Bajo
Develer S.r.l.
http://www.develer.com