[PyKDE] QString in PyQt4 - Request for Comments

[Phil Thompson]

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

I'm totally unsympathetic to the idea of a *separate* Pythonic API to Qt.
The Python GUI toolkit "market" is fragmented enough as it is - this would
only add more confusion for (relatively) little benefit.

People come to PyQt either as existing Python programmers looking for a
decent toolkit, or Qt/KDE programmers looking for a decent programming
language. I think the former is a larger group than the latter and this
difference will only become more pronounced with the Windows GPL version.

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.

Phil