[PyKDE] QString in PyQt4 - Request for Comments

[Giovanni Bajo]

David Boddie <david at boddie.org.uk> wrote:

> I wonder what it means to have a Pythonic API. Apart from transparent
> use of native types and classes, how could you make it so much more
> Pythonic? Allow direct access to properties as attributes? Change
> method names to lower case with underscores? I've got used to the
> value()/setValue()
> method naming convention for dealing with properties!

Some ideas:

1) Native types everywhere. This includes sizes, rects, containers, iterators
and whatnot.
2) Properties. I'd also make all the widget constructors accept an optional
initial value for all the properties as keyword arguments: QGroupBox(self,
insideSpaing=5, columns=4)
3) The signal/slot stuff is a little too complex, with its call to
QObject.connect. It inherits from the C++ interface. I'm sure a more Pythonic
syntax can be worked out.
4) Layout construction. I wonder why can't we have something which makes your
tree clearer:

HBoxLayout([
    VBoxLayout([
            Label("foo"),
            Label("bar")
    ]),
    QComboBox("option1 option2 option3".split(), readOnly=True),
    QButton(self, checked=true, tristate=true)
])


This would also allow to indent your code as to reflect the hierarchy, which
makes it much more readable.

5) Accessing a child by name could be magically be done as "self.child_name",
using __getattr__. This is especially useful for layout constructed as above to
access childs to do connections and whatnot.


> I'm sympathetic to the idea of a Pythonic API to Qt but, like you, I
> think that it should be provided by a higher level wrapper. There are
> some really good reasons for this:
>
>  1. The low level interface would still be accessible from Python.
>  2. Anyone concerned about performance can use the low level
>     interface. The people who want a higher level API probably
>     hopefully won't be too bothered by any extra latency that the
>     wrapper will introduce, and they can still use the low level
>     interface (or C++) if it turns out to be a problem.
>  3. The Pythonic wrapper can be done in Python rather than in the
>     binding layer. This means that it's easier for people to work on
>     it and customize its behaviour.
>  4. The wrapper doesn't have to be written by Phil. Hopefully, he
>     should be happy about that. ;-)


I totally agree with you.

Giovanni Bajo