[PyQt] Re: PyQt4 and Python 3.0

[Phil Thompson]

On Tue, 7 Oct 2008 11:34:24 +0200, Sundance <sundance at ierne.eu.org> wrote:
> Phil Thompson wrote:
> 
>> Regarding numbering, my current thinking is...
>> 
>> from PyQt4 import QtCore2, QtGui2
> 
> Hi all,
> 
> I would like to go out on a limb and share a few thoughts that came to 
> me with you guys.
> 
> Essentially, the name of PyQt4 seems to carry some embedded confusion, 
> in particular about what exactly the '4' applies to -- the whole PyQt, 
> or only the Qt part. That's not a bad thing in itself; for long, it has 
> been applying to both, so the double meaning is fitting.

Strictly speaking the '4' refers to PyQt and not Qt, but this is one case
where it's better if I agree with everybody else rather than insist on my
view of the world.

So I think the confusion is usually about the digits after the '4' rather
than the '4' itself.

> However, if the versioning of PyQt is going to become dissociated from 
> that of Qt, perhaps the naming scheme itself should reflect it.
> 
> It's not necessary to change the name of PyQt itself, although perhaps 
> that might be envisioned (anyone knows the name of a species of, err, 
> cute pythons?), but mostly it'd be about getting the 'Qt' part out of 
> the actual name so we could do something like:

The 'Qt' part of the name is ok, it's the version number that's the
problem. "Viper" can be "PyQt".

>   from Viper import Qt4
> 
> or
> 
>   from Viper.Qt3 import qt, qttable
> 
> or
> 
>   from Viper.Qt4.QtGui import *
> 
> ... and so on.
> 
> ('Viper' fails at both cute and python, I know. I suck with names, but 
> this is just an example, so please bear with me.)
> 
> In the above scheme, Viper would be a common namespace with three 
> purposes:
> 
> - Dissociating bindings versions from Qt versions (which is the main 
> issue that is being discussed in this here thread);

I've pretty much abandoned that idea (ie. PyQt5) anyway.

> - Raising a friendly, explanatory exception when trying to access a Qt 
> version for which no bindings are installed;
> - Raising an exception, I guess, if the user tries to import the 
> bindings for another version of Qt when there's already a different one 
> loaded (assuming that is even necessary).
> 
> I don't know how well SIP supports buildings against different versions 
> of Qt, but I suppose there is nothing to keep us from having one 
> different build for each Qt version anyway, exactly the way it 
> currently works -- only they'd all be installed under a common Viper 
> namespace.
> 
> I suppose such distributions as Debian would want to split the packaging 
> into viper-qt3, viper-qt4, and viper-common, which is entirely fine 
> with me.
> 
> With this neat module organisation in place, we could then ship the 
> bindings as "Viper x.y for Python 2.x" or "Viper x.y for Python 3" 
> without excessive confusion.
> 
> And we could have just as many Viper versions as we'd damn well please 
> within any given Python and Qt release timeframe -- we'd simply import 
> from Viper2, Viper3... rather than Viper.
> 
> Thoughts?

With 20/20 hindsight (starting 10 years ago) I should have done something
along these lines. I'm certainly not going to change the structure of PyQt3
at this stage.

At the moment I'm considering two possibilities...

from PyQt4 import QtCore2

...which has the disadvantage of the number of changes needed if you use
the QtCore2.QLabel() style (which I do), and...

from PyQt4v2 import QtCore

...which has the disadvantage of introducing another top-level package.

Maybe a third possibility...

from PyQt4.v2 import QtCore

Phil