[PyKDE] ANNOUNCE: PyQt/PyKDE v0.10pre5

[Phil Thompson]

Richard Jones wrote:

> >
> > 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.

I'm implementing the char* cast operator - repr() seems "closer" in
meaning to this than str().  It's coincidence that this operator, when
applied to a QString, produces a user viewable string.  SIP is a general
tool - it isn't just used for the Qt/KDE bindings.

>     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...

My view is that the bad design decision was the orginal one to map
QStrings onto Python strings - I'm now correcting that mistake. 
However, there is a choice...

I can very easily revert the Qt v1.x behavior to what it was in earlier
versions, but the Qt v2.x behavior will be done like this in order to
support Unicode. The disadvantage of mixing the two approaches is that
scripts won't be portable between the two.  What's the consensus?

Phil