On Mon, 06 Oct 2008 21:10:44 +0200, Giovanni Bajo <[EMAIL PROTECTED]>
wrote:
> On 10/6/2008 9:04 PM, Phil Thompson wrote:
>> 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.
>
> 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
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
