[PyQt] Re: PyQt4 and Python 3.0

[Phil Thompson]

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.

Phil