> Yes, I believe it would good to have two libraries. It's orthogonal to this > string issue though, but I wouldn't mind a more Pythonic way to use Qt. I'm > sure there are dozen of things that could be done easily in Python and are > harder in Qt because of C++. Of course, this is a totally different project, > because you'd get additional new different APIs to create and access the Qt > classes. I'm just saying that the scope of PyQt shouldn't be too make a > Python version of Qt: it should be to wrap Qt to Python.
That's a valid point, but I don't think it needs to be a 'totally separate project.' I understand the potential for incompatibility with two versions of PyQt, but what if they had different names? They can still be built from the same codebase, with %Feature directives. 'import qt' gets you QStrings and a very C++-esq API. Suitable for prototyping work. 'import pyqt' gets you python strings, dates, collections, etc. More appropriate for pure python work. Lets say both variants share the vast majority of their code, via a .so/.dll that is linked in the traditional way. The .pyd file contains the module structure, which has function pointers to our module's conversion routines. Sounds pretty crazy, eh? James _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
