> David Boddie <[EMAIL PROTECTED]> 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 _______________________________________________ PyKDE mailing list PyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde