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.
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
