[PyQt] Re: PyQt4 and Python 3.0

[Phil Thompson]

On Tue, 07 Oct 2008 00:29:12 -0700, Glenn Linderman <v+python at g.nevcal.com>
wrote:
> On approximately 10/6/2008 10:07 PM, came the following characters from 
> the keyboard of 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 think PyQt4 as is, with bug fixes if Python 2.6 breaks anything, is 
> adequate for 2.6.
> 
> 
>> 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
> 
> 
> So one would have to change all the import statements (not too bad) and 
> then all the constructor calls also?  xxx = QtCore2.someWidget ???  Ick. 
>   Could be automated, though...
> 
> Wouldn't it be easier on developers to make it
> 
> from PyQt4v2 import QtCore, QtGui

I quite like that.

>> 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.
> 
> 
> What's the point in fixing anything, without unifying QString and Python 
> string?  Or can you just ignore Python str (except for converting from 
> it), and unify QString and unicode?  And if you can, is the reason why 
> it wasn't just because it hadn't been thought of then, or that the 
> technology to do so wasn't understood, rather than it being technically 
> impossible? I'm too new to Py & Qt to understand the history here.

It was discussed during the development of PyQt4, but in the end I took a
conservative approach. Since then things like Jambi have come along with a
different approach which people don't seem to complain about.

> I can't speak for other users, but I'm mostly interested in seeing 
> something for Py3 for new applications.  Note that making PyQt4 on Py2 
> more Pythonic only helps those users that are willing to make a porting 
> or rewrite investment on that platform.
> 
> I'd actually rather see a port of PyQt4 to Py3 without (many) new 
> features, and then see the Pythonic rewrite happen there.

I think most people today will be planning to use Python 2 for new
(non-trivial) developments. Presumably that will change over time.

Phil