[PyQt] More pythonic API

[Florian Friesdorf]

On Wed, Jul 29, 2009 at 02:54:51PM +0100, Phil Thompson wrote:
> 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20090801/2d09a85e/attachment-0001.bin