[PyQt] More pythonic API

[Phil Thompson]

On Wed, 29 Jul 2009 14:44:54 +0200, Florian Friesdorf <flo at chaoflow.net>
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.

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

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

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

Phil