I am very pleased with the amount of discussion this topic has garnered! mutability: Strings in python are immutable for good reason. One being that they are considered a low-level data type that should behave like it's passed by value. (To modify a python string in some function, you have to return it and explicitly assign it to the original variable.) In practice, there is probably little danger of inadvertantly modifying a QString by reference, but the opportunity for confusion remains.
Mutability also means QStrings cannot be used as keys in a dict. (Came up recently on this list.) documentation: I was proposing Doxygen as a solution because it is capable of parsing the documentation that is already embedded in the Qt source. I believe it should be possible to navigate the data structures generated by Doxygen to make the appropriate changes for the Python version. The differences would be partially automatic, and partially based on rules or substitutions stored in another file. Doxygen could also produce output suitable for use as docstrings. Obviously, there is some non-trivial work here. compatibility: Using %Feature certainly would create two incompatible libraries. This is not something I had considered. In my scenario, it's also a non-issue. (Python is embedded into an application. No external PyQt code will be used in this environment, and none of the code written for this environment will be useful outside it.) A QString as mapped type option would have to be documented as potentially incompatible. I like Phil's idea for exported type converters. It still leaves us with a Python dialect of Qt, as opposed to a true Pythonic Qt API. I think the only valid argument I've seen for maintaining the status quo is compatibility with existing code. Of course, that's a bit of a trump card. For my own purposes, I am going to attempt to reimplement QString as a %MappedType. I want my users to have as low a barrier to entry as possible, and that means strings are string. Having multiple string types is a uniquely C++ problem, not something I wish to export into a language that is otherwise as tidy as Python. I do hope that this change makes it into the PyQt distrubution as an option with a big warning sign. James _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
