On 10/7/2008 7:07 AM, Phil Thompson wrote:
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.
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.
--
Giovanni Bajo
Develer S.r.l.
http://www.develer.com
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
