Hi, will there be PyQt4 support for Python 3.0 once it goes final? Regards, Detlev -- -- Detlev Offenbach detlev <at> die-offenbachs.de
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. Phil
On 2008-10-03, 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. I've been waiting for someone to mention this... Here's my personal "wish list" for Python 3/PyQt4 (including those that Phil is going to do as he says above): - No QString, only str, plus some static functions for things that str doesn't provide, e.g., QString.simplified(s : str) -> str - No QByteArray, only bytes (or bytearray) - No QVariant, only object - Guarantee that "from PyQt4.QtGui import *" and similar will only import objects whose name begins with capital Q. - Make PyQt more Pythonic. So use exceptions not error codes, for example, make QFile.open() raise an exception on error. Also, provide QDataStream.readColor(), QDataStream.readHostAddress(), etc., i.e., a reader and a writer _method_ for every QDataStream type for those allergic to << and >>. - Support Qt collection types that don't have Python equivalents, e.g.,(Continue reading)
On Fri, Oct 3, 2008 at 5:08 PM, Mark Summerfield <mark <at> qtrac.eu> wrote: > On 2008-10-03, Phil Thompson wrote: >> On Fri, 3 Oct 2008 17:11:19 +0200, Detlev Offenbach > Here's my personal "wish list" for Python 3/PyQt4 (including those that > Phil is going to do as he says above): > > - No QString, only str, plus some static functions for things that str > doesn't provide, e.g., QString.simplified(s : str) -> str > - No QByteArray, only bytes (or bytearray) > - No QVariant, only object > - Guarantee that "from PyQt4.QtGui import *" and similar will only > import objects whose name begins with capital Q. That'd be cool. An alternative that I think would be even better would be to provide a "Qt" namespace as per QtRuby and drop the Q prefix from the classes, so Qt.Application, Qt.Widget, &c. That'd dodge the ugly namespace pollution while not causing much more typing.
On Oct 3, 2008, at 2:15 PM, Paul A. Giannaros wrote:
> On Fri, Oct 3, 2008 at 5:08 PM, Mark Summerfield <mark <at> qtrac.eu>
> wrote:
>> On 2008-10-03, Phil Thompson wrote:
>>> On Fri, 3 Oct 2008 17:11:19 +0200, Detlev Offenbach
>> Here's my personal "wish list" for Python 3/PyQt4 (including those
>> that
>> Phil is going to do as he says above):
>>
>> - No QString, only str, plus some static functions for things that
>> str
>> doesn't provide, e.g., QString.simplified(s : str) -> str
>> - No QByteArray, only bytes (or bytearray)
>> - No QVariant, only object
>> - Guarantee that "from PyQt4.QtGui import *" and similar will only
>> import objects whose name begins with capital Q.
>
> That'd be cool. An alternative that I think would be even better
> would be to provide a "Qt" namespace as per QtRuby and drop the
> Q prefix from the classes, so Qt.Application, Qt.Widget, &c.
> That'd dodge the ugly namespace pollution while not causing
> much more typing.
While we're all chiming in, I'd like to add a vote for PEP8[0]
package and module naming. For example:
The main package:
PyQt4 -> pyqt4
(Continue reading)On 2008-10-03, Paul A. Giannaros wrote: > On Fri, Oct 3, 2008 at 5:08 PM, Mark Summerfield <mark <at> qtrac.eu> wrote: > > On 2008-10-03, Phil Thompson wrote: > >> On Fri, 3 Oct 2008 17:11:19 +0200, Detlev Offenbach > > > > Here's my personal "wish list" for Python 3/PyQt4 (including those that > > Phil is going to do as he says above): > > > > - No QString, only str, plus some static functions for things that str > > doesn't provide, e.g., QString.simplified(s : str) -> str > > - No QByteArray, only bytes (or bytearray) > > - No QVariant, only object > > - Guarantee that "from PyQt4.QtGui import *" and similar will only > > import objects whose name begins with capital Q. > > That'd be cool. An alternative that I think would be even better > would be to provide a "Qt" namespace as per QtRuby and drop the > Q prefix from the classes, so Qt.Application, Qt.Widget, &c. > That'd dodge the ugly namespace pollution while not causing > much more typing. I like that(Continue reading)But how do we then distinguish QtGui.QApplication from QtCore.QApplication? (Or does that even matter?) But I'm not keen on pyqt4 and other lowercase names as Daniel suggested. IMO lowercase is for Python's standard packages; I think mixed cased is best for own and third party to help avoid clashes.
On 03.10.08 21:59:14, Mark Summerfield wrote: > On 2008-10-03, Paul A. Giannaros wrote: > > On Fri, Oct 3, 2008 at 5:08 PM, Mark Summerfield <mark <at> qtrac.eu> wrote: > > > On 2008-10-03, Phil Thompson wrote: > > >> On Fri, 3 Oct 2008 17:11:19 +0200, Detlev Offenbach > > > > > > Here's my personal "wish list" for Python 3/PyQt4 (including those that > > > Phil is going to do as he says above): > > > > > > - No QString, only str, plus some static functions for things that str > > > doesn't provide, e.g., QString.simplified(s : str) -> str > > > - No QByteArray, only bytes (or bytearray) > > > - No QVariant, only object > > > - Guarantee that "from PyQt4.QtGui import *" and similar will only > > > import objects whose name begins with capital Q. > > > > That'd be cool. An alternative that I think would be even better > > would be to provide a "Qt" namespace as per QtRuby and drop the > > Q prefix from the classes, so Qt.Application, Qt.Widget, &c. > > That'd dodge the ugly namespace pollution while not causing > > much more typing. > > I like that(Continue reading)
On Fri, Oct 3, 2008 at 9:59 PM, Mark Summerfield <mark <at> qtrac.eu> wrote: > On 2008-10-03, Paul A. Giannaros wrote: >> On Fri, Oct 3, 2008 at 5:08 PM, Mark Summerfield <mark <at> qtrac.eu> wrote: >> > On 2008-10-03, Phil Thompson wrote: >> >> On Fri, 3 Oct 2008 17:11:19 +0200, Detlev Offenbach >> > >> > Here's my personal "wish list" for Python 3/PyQt4 (including those that >> > Phil is going to do as he says above): >> > >> > - No QString, only str, plus some static functions for things that str >> > doesn't provide, e.g., QString.simplified(s : str) -> str >> > - No QByteArray, only bytes (or bytearray) >> > - No QVariant, only object >> > - Guarantee that "from PyQt4.QtGui import *" and similar will only >> > import objects whose name begins with capital Q. >> >> That'd be cool. An alternative that I think would be even better >> would be to provide a "Qt" namespace as per QtRuby and drop the >> Q prefix from the classes, so Qt.Application, Qt.Widget, &c. >> That'd dodge the ugly namespace pollution while not causing >> much more typing. > > I like that(Continue reading)
On Fri, Oct 3, 2008 at 3:59 PM, Mark Summerfield <mark <at> qtrac.eu> wrote: > On 2008-10-03, Paul A. Giannaros wrote: >> On Fri, Oct 3, 2008 at 5:08 PM, Mark Summerfield <mark <at> qtrac.eu> wrote: >> > On 2008-10-03, Phil Thompson wrote: >> >> On Fri, 3 Oct 2008 17:11:19 +0200, Detlev Offenbach >> > >> > Here's my personal "wish list" for Python 3/PyQt4 (including those that >> > Phil is going to do as he says above): >> > >> > - No QString, only str, plus some static functions for things that str >> > doesn't provide, e.g., QString.simplified(s : str) -> str >> > - No QByteArray, only bytes (or bytearray) >> > - No QVariant, only object >> > - Guarantee that "from PyQt4.QtGui import *" and similar will only >> > import objects whose name begins with capital Q. >> >> That'd be cool. An alternative that I think would be even better >> would be to provide a "Qt" namespace as per QtRuby and drop the >> Q prefix from the classes, so Qt.Application, Qt.Widget, &c. >> That'd dodge the ugly namespace pollution while not causing >> much more typing. > > I like that(Continue reading)
On approximately 10/3/2008 8:18 AM, came the following characters from the keyboard of Phil Thompson: > 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. While these are excellent goals, and some of the other suggestions have merit, know that there is interest. Probably there are two classes of users; those wanting to port existing applications, that would want to see "compatibility wrappers" for existing code to allow a slow migration to the new APIs, and those that are writing new applications, and would like to bypass all the "old cruft". My personal situation is that I have only recently begun writing my first major PyQt application, using Python 2.5 and PyQt 4. This will take me "a while" also. Depending on how long our "a while"s are, I hope to probably release the application using Python 3.0 and the appropriate PyQt (be it 4 or 5 or whatever). Any suggestions you can make regarding how to best approach writing code(Continue reading)
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 j
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.(Continue reading)
On Mon, 06 Oct 2008 19:42:26 +0200, Giovanni Bajo <rasky <at> develer.com> 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.(Continue reading)
On 10/6/2008 8:42 PM, Phil Thompson wrote: > On Mon, 06 Oct 2008 19:42:26 +0200, Giovanni Bajo <rasky <at> develer.com> > 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. >>(Continue reading)
On Mon, 06 Oct 2008 20:52:50 +0200, Giovanni Bajo <rasky <at> develer.com> wrote: > On 10/6/2008 8:42 PM, Phil Thompson wrote: >> On Mon, 06 Oct 2008 19:42:26 +0200, Giovanni Bajo <rasky <at> develer.com> >> 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.(Continue reading)
On 10/6/2008 9:04 PM, Phil Thompson wrote: > On Mon, 06 Oct 2008 20:52:50 +0200, Giovanni Bajo <rasky <at> develer.com> > wrote: >> On 10/6/2008 8:42 PM, Phil Thompson wrote: >>> On Mon, 06 Oct 2008 19:42:26 +0200, Giovanni Bajo <rasky <at> develer.com> >>> 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.(Continue reading)
On Mon, 06 Oct 2008 21:10:44 +0200, Giovanni Bajo <rasky <at> develer.com> wrote: > On 10/6/2008 9:04 PM, Phil Thompson wrote: >> On Mon, 06 Oct 2008 20:52:50 +0200, Giovanni Bajo <rasky <at> develer.com> >> wrote: >>> On 10/6/2008 8:42 PM, Phil Thompson wrote: >>>> On Mon, 06 Oct 2008 19:42:26 +0200, Giovanni Bajo <rasky <at> develer.com> >>>> 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(Continue reading)
On lun, 2008-10-06 at 20:19 +0100, Phil Thompson wrote: > On Mon, 06 Oct 2008 21:10:44 +0200, Giovanni Bajo <rasky <at> develer.com> > wrote: > > On 10/6/2008 9:04 PM, Phil Thompson wrote: > >> On Mon, 06 Oct 2008 20:52:50 +0200, Giovanni Bajo <rasky <at> develer.com> > >> wrote: > >>> On 10/6/2008 8:42 PM, Phil Thompson wrote: > >>>> On Mon, 06 Oct 2008 19:42:26 +0200, Giovanni Bajo <rasky <at> develer.com> > >>>> 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(Continue reading)
On 2008-10-06, Giovanni Bajo wrote: [snip] > "PyQt5" seems confusing to me when/if Qt5 comes out (and I always find > confusing that PyQt4 version number is too similar to Qt version number; > I'd go for something totally different like "PyQt4 version 18"). I also think PyQt5 would be confusing; and agree with Giovanni that a completely different numbering scheme for PyQt would be better. At first I used to think that say, PyQt 4.2 meant you needed Qt 4.2, when in fact you can use earlier Qt 4's with it. Something like PyQt4-25 or PyQt4/25 suggests to me "version 25 of PyQt4 for Qt 4.x" Or maybe something more explicit: PyQt25/Qt4? -- -- Mark Summerfield, Qtrac Ltd, www.qtrac.eu C++, Python, Qt, PyQt - training and consultancy "C++ GUI Programming with Qt 4" - ISBN 0132354160
On Tuesday 07 October 2008, Mark Summerfield wrote: > On 2008-10-06, Giovanni Bajo wrote: > [snip] > > > "PyQt5" seems confusing to me when/if Qt5 comes out (and I always find > > confusing that PyQt4 version number is too similar to Qt version number; > > I'd go for something totally different like "PyQt4 version 18"). > > I also think PyQt5 would be confusing; and agree with Giovanni that a > completely different numbering scheme for PyQt would be better. At first > I used to think that say, PyQt 4.2 meant you needed Qt 4.2, when in fact > you can use earlier Qt 4's with it. Something like PyQt4-25 or PyQt4/25 > suggests to me "version 25 of PyQt4 for Qt 4.x" Or maybe something more > explicit: PyQt25/Qt4? Py3Qt4? Or too many numbers?
On Montag, 6. Oktober 2008, Phil Thompson wrote: > On Mon, 06 Oct 2008 19:42:26 +0200, Giovanni Bajo <rasky <at> develer.com> > > 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(Continue reading)
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*(Continue reading)
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. >>(Continue reading)
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.(Continue reading)
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.(Continue reading)
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. >>>>(Continue reading)
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(Continue reading)
On approximately 10/7/2008 10:05 AM, came the following characters from the keyboard of Phil Thompson: > 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. Yet moving to 2.6 as a stepping stone to 3.0 seems to be recommended by the Py3 devs because 1) future features exist 2) 2to3 is shipped with 2.6 3) maybe I've missed some other reasons On the other hand, there may be no particular reason to ship a product based on 2.6 if the goal is to move from 2.x to 3.0... perhaps this is what you mean? But some of the tools available in 2.6 can help the transition from 2.x to 3.0... a stepping stone it seems intended to be... -- -- Glenn -- http://nevcal.com/ =========================== A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
On approximately 10/3/2008 8:18 AM, came the following characters from the keyboard of Phil Thompson: > 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. While these are excellent goals, and some of the other suggestions have merit, know that there is interest. Probably there are two classes of users; those wanting to port existing applications, that would want to see "compatibility wrappers" for existing code to allow a slow migration to the new APIs, and those that are writing new applications, and would like to bypass all the "old cruft". My personal situation is that I have only recently begun writing my first major PyQt application, using Python 2.5 and PyQt 4. This will take me "a while" also. Depending on how long our "a while"s are, I hope to probably release the application using Python 3.0 and the appropriate PyQt (be it 4 or 5 or whatever). Any suggestions you can make regarding how to best approach writing code(Continue reading)
RSS Feed