Henrik Pauli wrote: >> 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.
Hi, Maybe I didn't express myself clearly, but in my thinking, 'Viper' versions and Python versions would be orthogonal, so Viper2, Viper3... would be referring to the respective versions of the bindings, NOT the versions of Python. The whole /point/ would be to be independant of the Python versioning scheme. :) In other words, a given version of 'Viper' could conceivably be designed to be able to build against both Python 2 and Python 3, although of course a later version would eventually drop support for Python 2. That's what drove the organisation of the scheme I posted about: it allows smooth transitioning between versions of Python as well as between versions of Qt -- without making it mandatory, either, because supporting several Python versions with one build is bound to be a lot of work that Phil may not want to undertake. Also, Phil wrote: > 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. Oh, you are absolutely correct, of course. The only point of giving the product a whole new name like 'Viper' (or whatever the heck, really) would be to make /your/ view, which I happen to agree with, unambiguous to everybody else. > The 'Qt' part of the name is ok, it's the version number that's the > problem. "Viper" can be "PyQt". You are of course entirely right. To complement on the above, the only reason why I put this notion forward is that 'import Viper5.Qt4' is perhaps one little bit less confusing than 'import PyQt5.Qt4', in, well, the everybody-else's-worldview you were referring to. (Plus the numbering of Viper or whatever could conceivably start over at 1 instead of picking up that of PyQt, I really don't care either way.) You also suggest the 'from PyQt4v2 import QtCore' and 'from PyQt4.v2 import QtCore' schemes, in which, if I'm not mistaken, the '4' in PyQt4 would now start referring to the Qt version, is that correct? If so, the scheme would be functionally equivalent to what I suggested, minus the possibility to support different Qt versions within one PyQt version, which is really no big deal AFAIC. So the only issues left would then be possible ambiguities with the current PyQt4 module's organisation, and, well, aesthetics. On that note, please don't go with 'from PyQt4 import QtCore2'. :) If the module's name is QtCore in Qt, it should be QtCore in the bindings as well. Plus I can already foresee namespace clashes with that scheme. Thanks, -- S. _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
