[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    Re: [PyKDE] QString in PyQt4 - Request for Comments
From:       "Giovanni Bajo" <rasky () develer ! com>
Date:       2005-10-20 12:42:43
Message-ID: 014001c5d573$c40ae1d0$bf03030a () trilan
[Download RAW message or body]

Simon Edwards <simon@simonzone.com> wrote:

> We could do something ugly like make QTextEdit.text() return a Python
string
> (which is what most people want most of the time), and then add a keyword
> argument "qstring_please" for the case where QString is desired...
optimises
> the common case (for people) and makes the not so common case possible...

I wouldn't mind this. I wouldn't even mind a global option like
qt.returnQStringPlease(True).

>> but those can find their place in a
>> library which wraps Qt/PyQt with the goal to provide a more Pythonic API.
>
> You want 2 libraries?
>
> How practical is it anyway to replace the Python wrapper of QTextEdit, for
> example, with an extended version (Python code) that adds more Pythonic
> goodness?


Yes, I believe it would good to have two libraries. It's orthogonal to this
string issue though, but I wouldn't mind a more Pythonic way to use Qt. I'm
sure there are dozen of things that could be done easily in Python and are
harder in Qt because of C++. Of course, this is a totally different project,
because you'd get additional new different APIs to create and access the Qt
classes. I'm just saying that the scope of PyQt shouldn't be too make a
Python version of Qt: it should be to wrap Qt to Python.

This string issue is of course very borderline, and I don't think it's
inappropriate for PyQt to return Python strings from methods, as long as
there is still a way to access QStrings if needed for any reason.
-- 
Giovanni Bajo

_______________________________________________
PyKDE mailing list    PyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[prev in list] [next in list] [prev in thread] [next in thread]