[PyQt] Re: PyQt4 and Python 3.0

[Phil Thompson]

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.

Phil