[PyKDE] QString in PyQt4 - Request for Comments
phil at riverbankcomputing.co.uk
Fri Oct 21 09:02:57 BST 2005
> 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
>> method naming convention for dealing with properties!
> Some ideas:
> 1) Native types everywhere. This includes sizes, rects, containers,
> and whatnot.
> 2) Properties. I'd also make all the widget constructors accept an
> 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
> syntax can be worked out.
> 4) Layout construction. I wonder why can't we have something which makes
> tree clearer:
> 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,
> makes it much more readable.
> 5) Accessing a child by name could be magically be done as
> 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.
More information about the PyQt