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

[Richard Jones]

[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