On Tue, 07 Oct 2008 00:29:12 -0700, Glenn Linderman <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> >> wrote: >>> On Mon, Oct 6, 2008 at 7:33 PM, Doug Bell <[EMAIL PROTECTED]> 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 >>>>>>> <[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 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 _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
