[PyKDE] Re: QString vs PyString

[James Emerton]

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