On Friday 03 June 2005 10:50 pm, James Emerton wrote: > On 6/3/05, Jim Bublitz <[EMAIL PROTECTED]> wrote: > > On Friday 03 June 2005 11:40, Matej Cepl wrote: > > > And why do you have to use QString at all? Cannot you just use Python's > > > native strings/unicode strings? Read more about the relationship > > > between Python's and Qt-string machinery read > > > http://www.opendocs.org/pyqt/index.lxp?lxpwrap=c2029%2ehtm > > > > Because a lot of Qt/KDE methods return a QString. > > > > I view it as a difference in philosophy between simply providing an > > interface from Qt to Python vs. writing a Python-based API based on Qt. > > The latter provides a lot more problems in documentation, complexity and > > room for error, and is probably less attractive to people who write > > mixed-language applications using Qt and PyQt. > > To subtly paraphrase your comment... > > The former provides a lot of problems in documentation, complexity, > and room for error, and is probably less attractive to people who > write mixed-API applications using PyQt and C++. > > In my particular usage scenario, there is a huge need for making > things as simple as possible for people writing the Python. I want to > empower any given third party (with the appropriate license) to > leverage our business API and the Qt GUI to customize their > application. (This is one of three major reasons for incorporating a > Python interpreter, the other two being development time, and runtime > flexibility.) > > Imagine that the target audience is someone who could learn VB in a > couple weeks. They get access to all our Python code to modify as > they like, and to learn from for the development of their own modules. > > This is someone that's not going to understand why they get a > ArgumentError when they write WonkString( someLineEdit.text() ) where > WonkString() is some C++ function that wants a QString. > > I will concede that this does result in some difficulty with > documentation. I think that it's a surmountable problem though. I > believe Doxygen can already parse the embedded Qt documentation. A > tool that did some translation to more Python appropriate > documentation, would be a good thing. (I appreciate that someone > needs to write this part; and it's not exactly glamorous work. > Eventually, I would probably undertake this myself.)
There are two things here - generating a Pythonic version of the Qt documentation, or just generating a Pythonic description of the API calls, arguments and return types. The former is difficult because it still needs huge amounts of human intervention to edit the text - converting embedded C++ example code to Python, removing unsupported methods etc. The latter is trvial - SIP already does it for QScintilla API files and I've been meaning to extend it for automatically generated docstrings and/or html/ReST/XML. > > I find it annoying to have to use str() or s.latin1(), but over all I > > prefer a minimum of tampering with the Qt API. > > It seems from the traffic on this list that the primary users of PyQt > are not C++/Qt developers coming to PyQt, but Python (or newbie) > developers in need of a better UI than Tk. Those few people writing > multi-language apps have already cleared a large hurdle in marrying > Python with another language. I don't think it's a big leap to say > "There is no QString, all strings are translated to the Python native > string type." With the increasing awareness of Python in the KDE community I think you will see a lot more C++/Qt programmers coming to PyQt/PyKDE. > Obviously, there is going to be a lot of code out there that relies on > QString being part of the PyQt API. That means ripping it out by the > roots would be disastrous. There is also the problem of whether to > create string or unicode objects. That's why I'd like to do this as a > %Feature. Then you end up with two incompatible versions of the API. What if a user wants to run two applications each requiring a different version? > I am quite willing to make the changes required, but I'm looking for > feedback because there are people who have more experience at this > than I do. I'd also like to know if this could be included into the > PyQt distribution, because nothing sucks more than maintaining a > modified code base. I think the best approach is to implement a separate std module. This could be as comprehensive as you want to make it. You could either fully wrap std::string or you could just implement it as a %MappedType with convertors to and from appropriate Python types. The only problem would be automatically converting a QString to a std::string in the std module without introducing Qt as a build-time dependency on the std module. (In theory) I don't have a problem changing SIP to support the "publishing" of type convertors to other modules. In other words, PyQt publishes the convertor between a QString and a std::string so that it can be called by the std module without the latter caring what a QString is. Phil _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
