[PyKDE] QString in PyQt4 - Request for Comments

[Gerard Vermeulen]

On Fri, 21 Oct 2005 08:28:30 -0700 (PDT)
Tony Willis <Tony.Willis at nrc-cnrc.gc.ca> wrote:

> > Date: Fri, 21 Oct 2005 11:35:55 +0200
> > From: "Giovanni Bajo" <rasky at develer.com>
> > Subject: Re: [PyKDE] QString in PyQt4 - Request for Comments
> > To: "Phil Thompson" <phil at riverbankcomputing.co.uk>
> > Cc: pykde at mats.imk.fraunhofer.de
> > Message-ID: <01ce01c5d622$d616d5a0$bf03030a at trilan>
> > Content-Type: text/plain;	charset="iso-8859-1"
> >
> > Phil Thompson <phil at riverbankcomputing.co.uk> wrote:
> 
> > > I'm completely open to making the existing API more Pythonic - this is the
> > > time to do it. For example, I did casually float the idea of not using C++
> > > types in signal signatures in a previous post - but nobody bit.
> 
> > I didn't, because of the reasons explained previously: I believe it would
> > just cause more confusion, in the current PyQt design. It's just too handy
> > to go looking to the signature in the Qt Assistant and use it. I don't want
> > to go check in two different manuals. Until now, PyQt's goal has been to
> > adhere as much as possible to Qt, to not confuse existing Qt users and I
> > think it's a noble goal. I also understand that this is not ideal for a
> > Python-only programmer.
> > --
> > Giovanni Bajo
> 
> My $0.02 worth of option on this issue. I feel its indeed important that
> there be a Python interface to Qt that reflects the C++ interface as
> closely as possible. Whenever I have a problem or need to find out
> something about a Qt class member I first bring up Assistant and look there.
> I wouldn't want to have to remember that I'm using PyQt and first
> look in some other manual. I use another python package which interfaces
> to a 3rd party add-on package that makes use of Qt (Qwt). There are
> some calls in PyQwt which do not correspond to the C++ interface
> (yes, I realize that sometimes modifications cannot be avoided). However
> I've wasted time in the past trying to figure out why something
> wasn't working only to have to grope deeply into the PyQwt docs to
> discover that the Python interface was different to the Qwt C++ method.
> 
> I have no objection to someone developing a 'Pythonic' (I'm always
> curious as to exactly what this means) wrapper interface to Qt if they
> wish, but I think it important that lower level interfaces be available
> as much as possible.
> 

Happy (but sorry for Tony) to see one of my users bring up suffering from
'Pythonic' features because of documentation problems.  I do not know
exactly what Tony is referring to, but I am sure the feature is more
'Pythonic' and that I have documented it.

There is a Pythonic solution for such cases: 

--> doc strings

They have been on the TODO list for a long time.  I am using doc-strings
all the time, if I can.


I fully agree with Toni and Giovanni that a PyQt API close to the C++ API
of Qt is important for anybody who makes heavy use of PyQt out of the context
of Qt-Designer.  Only people with exceptional memories can do that without
Qt-Assistant and using two manuals is too much.


Some comments on the Giovanni's ideas (hate to see them implemented in
a separate Python layer):

(1) support for iterators if it can be implemented efficiently. Great.
(2) setting of properties by means of keyword arguments.  In the days
    before SIP-4, PyQwt offered this possibility by patching the
    Python wrapper which imported the library containing the C++ extension
    It worked for all methods of the form setThing(Thing t, ..).
    I was obliged to remove this feature when SIP-4 was introduced, with
    regret because it was a nice way to group all initialization in a single
    statement.
    It should not 'simple' to make SIP generate C++ code which does the same.
(4) I like this idea of layout construction, enough that it will enter
    my secret personal toolkit someday.

I hate to see QStrings disappear, because I think the alternative will
require more memory and for some programs the memory footprint will become
excessive.  Wouldn't it be possible to control if methods return QStrings
or Python strings at runtime on module level or by passing an extra argument?

Gerard