[PyQt] Re: PyQt4 and Python 3.0

[Sundance]

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.

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:

  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);
- 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?

-- S.