On Wed, Jul 29, 2009 at 02:54:51PM +0100, Phil Thompson wrote: > On Wed, 29 Jul 2009 14:44:54 +0200, Florian Friesdorf <[email protected]> > wrote: > > Hello, > > > > Based on a longer python history and no Qt experience, I'm just starting > > with PyQt. My enthusiasm is a bit slowed down by the non-pythonic API: > > > > a = QAction() > > a.setEnabled(True) > > enabled = a.isEnabled() > > > > setting = QSettings() > > filename = 'some.file' > > qfilename = QVariant(QString(filename)) > > settings.setValue("LastFile", qfilename) > > filename = settings.value("LastFile").toString() > > > > Preferably these would look something like: > > > > a = QAction() > > a.enabled = True > > enabled = a.enabled > > This is fairly easy to implement but would be an incompatible change.
I wouldn't like having my code rely on a specially built PyQt. Is it possible to generate these bindings as extra add-on modules? > > settings = QSettings() > > filename = 'some.file' > > You can do this now. With the current version of PyQt you never need to > explicitly create a QVariant. In the next version of PyQt (v4.6) QVariant > and QString will be (optionally) gone completely. great! > > settings["LastFile"] = filename > > filename = settings["LastFile"] > > > > One thing here is the implicit use of __getitem__() and __setitem__() > > instead of two different explicit functions. The other is a translation > > of QVariant to string and vice versa. > > > > - Are there any wrappers available that translate to a more > > pythonic API, i.e. not just direct bindings? > > Not yet - see below. > > > - Could SIP be extended to create these, i.e. would it be > > sane to have SIP extended to create these? > > It can be done, but not automatically. You would need to implement each > Pythonic feature with (a small amount of) handwritten code. I'd like to take a look on it. Can you give me some pointers? > > - Are there any plans to work towards a more pythonic API? > > - Am I the only one getting cognitive dissonance when programming with > > the less pythonic versions? > > I think that tends to be counter-balanced by the fact that Qt is very > consistent in its API (therefore predictable) and the documentation is > clear and easy to use. > > That said, I am currently working on a declarative layer on top of PyQt. > The purpose is *not* to have an alternative API, but to have a > complementary one that is good for the more boring parts of GUI design > (forms, dialogs etc). that sounds great! thank you very much! florian
pgpGqM8d4GN92.pgp
Description: PGP signature
_______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
