On Wednesday 19 October 2005 09:47, Phil Thompson wrote: > On Wednesday 19 October 2005 1:17 am, David Boddie wrote:
> > * Maintenance of QStrings passed to Python implemented methods - > > sometimes it's good to keep things in the same form that they were > > supplied in, although maybe it's not as important for QStrings as it is > > for, say, QImages. > > Examples? It would be possible to add an annotation to SIP, something > like /GetWrapper/ so that %MethodCode could be given the C++ address as a > void *. I can't think of any QString examples. There was a problem with QImages and ThumbCreators, but that's a different story. > > * Codecs - does Python support the same range of codecs as Qt? > > As a mono-lingual Brit, that's one of my implied questions - is Python's > unicode support good enough to be used instead of Qt's? After a brief desperate search at the Python prompt, I searched the web for a page with this information and found this: http://docs.python.org/lib/standard-encodings.html So it seems that Python may support a superset of codecs. The list of codecs supported by Qt 4 can be found on this page: http://doc.trolltech.com/4.0/qtextcodec.html You would need to ask whether people find themselves handling encoded text with Python's built-in types rather than with QString and QTextCodec. > > It would be also interesting to consider whether QStrings could be cached > > to avoid lots of copying between QString and unicode objects. > > While it's easy enough to create a sub-type of the Python unicode type that > keeps an optional QString copy, I can't see how to make it any easier to > use than QString. You'd have to create it with some sort of ctor. The > alternative approach of keeping a separate map of string/unicode objects to > QStrings gives you problems with garbage collecting the map. (Python > string/unicode objects don't support weak references.) Sounds like more trouble than it's worth. :-/ > I've always promoted PyQt's use as a rapid prototyping tool where you > eventually re-write the prototype in C++ - but I'm not convinced that > anybody actually does this. With the availability of GPL Qt for Windows I > hope/expect that there will be many new users for PyQt4 (new to Python as > well as new to Qt, and with no experience of C++) so eliminating C++isms is > more important to me now than it has been in the past. Apart from vague worries about codec support, I suppose the only concerns I have are about performance and documenting Python-specific behaviour. David _______________________________________________ PyKDE mailing list PyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde