On Tuesday 07 October 2008, Sundance 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.
>
> 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.
Hmmm, true that, but since Py2 and Py3 are completely different matters (as
far as I understand), thus have completely separate module bases, it could be
just Viper in both, without clashing whatsoever.
Debian would probably package it as python-viper-* and python3000-viper-* and
so keep both separate even if they share a name.
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
