[PyQt] Re: PyQt4 and Python 3.0

[Phil Thompson]

On Mon, 6 Oct 2008 21:30:49 -0500, "Arthur Pemberton" <pemboa at gmail.com>
wrote:
> On Mon, Oct 6, 2008 at 7:33 PM, Doug Bell <dougb at bellz.org> wrote:
>> Giovanni Bajo 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 disagree, for several reasons:
>>
>>  - Doing the changes separately means maintaining three separate
>>    versions of PyQt at once, taking more of Phil's time and promoting
>>    confusion.
>>
>>  - Many Linux distros are unlikely to support all three versions at
>>    once.
>>
>>  - The QString changes are somewhat related to Python 3's unicode
>>    string changes.  Both changes would affect the same portions of
>>    application code.
>>
>>  - I agree that porting an application with both sets of changes is
>>    tougher than doing one change alone, but it's still easier to
>>    thoroughly test my applications once, rather than twice.
> 
> 
> My humble opinion:
> 
> Take some time with the community, collect opinion on all the bad
> parts of PyQt, and then make a clean break to rewrite PyQt4 for Python
> 2.6, making use of future features whenever possible.

I definitely won't be targeting 2.6 for anything. The idea that people will
move their 2.x code to 2.6, and then move it again to 3.0 is, to me, crazy.

I will set something up to gather opinion and to present my current
thinking. I will particularly need help in identifying individual methods
that should be made more Pythonic.

Regarding numbering, my current thinking is...

from PyQt4 import QtCore2, QtGui2

The maintenance burden won't be too bad as there would still only be one
source package. configure.py would have flags to build the different
variants.

Note that a side effect of all this is that Python3 support drops down the
priority list (by a long way) as making PyQt4 for Python2 more Pythonic
will benefit significantly more users.

Phil