[Phil Thompson]
> PyQt/PyKDE v0.10pre5 is in the usual place at
> http://www.river-bank.demon.co.uk/software/private/. I've fixed all the
> bugs I know about and, unless you find anything new, this will be
> released later as v0.10 - so this is your last chance.
>
> Changes since v0.10pre4...
>
> SIP generates the correct #line directives after handwritten code.
> (Hannes - can you check this, I probably haven't got it exactly right.)
>
> QString and QByteArray are now regular classes and are not mapped
> automatically to Python strings. THIS MAY BREAK EXISTING PROGRAMS. You
> can still supply a Python string where a QString is expected, and the
> bindings will automatically translate, but if you specifically need a
> Python string then you will need to explicitly convert it using either
> the Python repr() function or reverse quotes. For example, the
> following line will no longer work...
>
> s = QString() + 'xyz'
>
> ...instead you do either...
>
> s = repr(QString()) + 'xyz'
>
> ...or...
>
> s = `QString()` + 'xyz'
>
> While this change isn't strictly necessary at this stage, it will be
> needed for Qt v2's Unicode support - so it's best to get used to it now.
I haven't used the code yet - but I have a couple of user-oriented comments
I'd like to make...
Firstly, I'm wondering why you're using repr() to obtain a string instead of
str(). str() is used to create a user-viewable string whereas repr() is used to
generate a string representation of an object. From the Library Reference:
str(object): Return a string containing a nicely printable
representation of an object. For strings, this returns the string
itself. The difference with repr(object) is that str(object) does
not always attempt to return a string that is acceptable to eval();
its goal is to return a printable string.
Secondly, why alter the existing mechanisms at all? And this is a very
personal opinion about API design, so feel free to shoot me down :) Basically,
when I am designing an API, my primary aim is to make the API user's life as
easy as possible. In this case, this translates to returning a Python string
from calls to text() [or some similar function] instead of forcing the API
user's code to convert the value. This gives us two possibilities:
1. have the text() method return a Python string and provide an
asUnicode() or asQObject() method to return a QString object, or
2. have the text() method return a QObject an provide an asString() method
which returns a Python string.
I forsee many run-time bugs and thus much anguish caused by forcing the API
user to convert the return value of .text() methods into Python strings...
All IMHO of course.
Richard