Simon Edwards <[EMAIL PROTECTED]> wrote: > We could do something ugly like make QTextEdit.text() return a Python string > (which is what most people want most of the time), and then add a keyword > argument "qstring_please" for the case where QString is desired... optimises > the common case (for people) and makes the not so common case possible...
I wouldn't mind this. I wouldn't even mind a global option like qt.returnQStringPlease(True). >> but those can find their place in a >> library which wraps Qt/PyQt with the goal to provide a more Pythonic API. > > You want 2 libraries? > > How practical is it anyway to replace the Python wrapper of QTextEdit, for > example, with an extended version (Python code) that adds more Pythonic > goodness? 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. This string issue is of course very borderline, and I don't think it's inappropriate for PyQt to return Python strings from methods, as long as there is still a way to access QStrings if needed for any reason. -- Giovanni Bajo _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
