[PyQt] Re: PyQt4 and Python 3.0

[Phil Thompson]

On Tue, 07 Oct 2008 18:06:05 +0200, Giovanni Bajo <rasky at develer.com>
wrote:
> On 10/7/2008 7:07 AM, Phil Thompson wrote:
>> 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.
> 
> FWIW, it's what every business user of Python I'm in contact with is 
> going to do.
> 
> I can't see an application with eg. 50K lines of Python code being 
> rewritten from scratch for Python 3.0 so that it ends up being 20% 
> slower on 3.0, and you get a couple years of development with no 
> intermediate releases.
> 
> Instead, migrating any codebase of moderate size to a new 2.x version is 
> usually quite easy (once all the 3rd party libraries are out of course) 
> and doesn't take more than a couple weeks altogether. It also has the 
> immediate benefits of getting the speedup of the new compiler and the 
> new builtin libraries/functions. So the tradeoff is usually acceptable.
> 
> Once the application is so trivially moved to 2.6, it can be slowly 
> moved to 3.0 feature by feature, module by module, by the means of 
> future imports and -3. This will probably take *years* after 3.0 is out 
> because it won't never be a priority (and by that time, I also hope 3.0 
> will be faster). And this is s perfectly fine and within the timelines 
> that Guido proposes for Python 2.x and 3.x.

I didn't mean to suggest that 2.6 wasn't worth using, only that to move to
it *only* as a stepping stone to 3.0 wasn't sensible.

Phil