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

[Richard Jones]

[Phil Thompson]
> >    Firstly, I'm wondering why you're using repr() to obtain a string instea
> d of
> > str(). str() is used to create a user-viewable string whereas repr() is use
> d 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.

   I would still feel more comfortable calling str(), even if it passes 
straight through to a __repr__ -- as with a lot of cases in Python.


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

   I'd be interested to know what the general Python approach to Unicode is. I 
guess it'd be nice to just seamlessly move from python 1.5 & Qt 1.x to python 
1.6 & Qt 2.x with no buggering around with repr() ;)

   I've just had a poke around, but couldn't find any concrete information on 
how Unicode in Python is going...


       Richard