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

Richard Jones Richard.Jones at fulcrum.com.au
Mon Dec 6 00:10:34 GMT 1999

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


More information about the PyQt mailing list