More pythonic API

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

More pythonic API

Florian Friesdorf-2
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

settings = QSettings()
filename = 'some.file'
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?
- Could SIP be extended to create these, i.e. would it be
  sane to have SIP extended to create these?
- 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?


best regards
florian

_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: More pythonic API

Arve Knudsen-2
My impression is that Phil intends for PyQt to generally resemble Qt as closely as practically feasible. This approach has advantages. It implies less complexity wrapping-wise, since the mapping is mostly direct, and once you know Qt itself you can easily work with PyQt (principle of least surprise). I find that PyQt being non-Pythonic mostly represents a threshold, which has little practical bearing once you have some experience with (Py)Qt. Also, it's a good thing when switching back and forth between C++ and Python (which some of us do).

Arve

On Wed, Jul 29, 2009 at 2:44 PM, Florian Friesdorf <[hidden email]> 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

settings = QSettings()
filename = 'some.file'
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?
- Could SIP be extended to create these, i.e. would it be
 sane to have SIP extended to create these?
- 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?


best regards
florian

_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt


_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: More pythonic API

Phil Thompson-5
In reply to this post by Florian Friesdorf-2
On Wed, 29 Jul 2009 14:44:54 +0200, Florian Friesdorf <[hidden email]>
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
_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: More pythonic API

Arve Knudsen-2
On Wed, Jul 29, 2009 at 3:54 PM, Phil Thompson <[hidden email]> wrote:
> - 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?

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

Sounds exciting, a declarative layer could prove really useful.

Arve

_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: More pythonic API

Florian Friesdorf-2
In reply to this post by Phil Thompson-5
On Wed, Jul 29, 2009 at 02:54:51PM +0100, Phil Thompson wrote:

> On Wed, 29 Jul 2009 14:44:54 +0200, Florian Friesdorf <[hidden email]>
> 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

_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: More pythonic API

Florian Friesdorf-2
In reply to this post by Arve Knudsen-2
On Wed, Jul 29, 2009 at 03:53:01PM +0200, Arve Knudsen wrote:
> My impression is that Phil intends for PyQt to generally resemble Qt as
> closely as practically feasible. This approach has advantages. It implies
> less complexity wrapping-wise, since the mapping is mostly direct, and once
> you know Qt itself you can easily work with PyQt (principle of least
> surprise). I find that PyQt being non-Pythonic mostly represents a
> threshold, which has little practical bearing once you have some experience
> with (Py)Qt. Also, it's a good thing when switching back and forth between
> C++ and Python (which some of us do).

I fully understand that and I am just starting with PyQt. Currently, I
think it would be great to have a layer on top of PyQt, that makes it
more pythonic. Maybe the declarative layer, Phil mentioned, will help
here. I'll be silent about that until I finished Mark's book and
actually wrote some real code.

-florian

_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: More pythonic API

Phil Thompson-5
In reply to this post by Florian Friesdorf-2
On Sat, 1 Aug 2009 11:46:59 +0200, Florian Friesdorf <[hidden email]>
wrote:

> On Wed, Jul 29, 2009 at 02:54:51PM +0100, Phil Thompson wrote:
>> On Wed, 29 Jul 2009 14:44:54 +0200, Florian Friesdorf <[hidden email]>
>> 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?

They'd have to be replacements not add ons.

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

Read the SIP documentation. You'd be implementing __getitem__ etc with
%MethodCode.

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

Phil
_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: More pythonic API

Florian Friesdorf-2
On Sat, Aug 01, 2009 at 10:51:27AM +0100, Phil Thompson wrote:

> On Sat, 1 Aug 2009 11:46:59 +0200, Florian Friesdorf <[hidden email]>
> wrote:
> >> > a = QAction()
> >> > a.setEnabled(True)
> >> > enabled = a.isEnabled()
> >> > (..)
> >> >
> >> > 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?
>
> They'd have to be replacements not add ons.
Only, iff there is a collision between those APIs, or?
In the above example, at least, it should work to have them both,
eventually using nasty monkey-patching.

> > I'd like to take a look on it. Can you give me some pointers?
>
> Read the SIP documentation. You'd be implementing __getitem__ etc with
> %MethodCode.

thx

florian

_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: More pythonic API

Phil Thompson-5
On Sat, 1 Aug 2009 11:55:59 +0200, Florian Friesdorf <[hidden email]>
wrote:

> On Sat, Aug 01, 2009 at 10:51:27AM +0100, Phil Thompson wrote:
>> On Sat, 1 Aug 2009 11:46:59 +0200, Florian Friesdorf <[hidden email]>
>> wrote:
>> >> > a = QAction()
>> >> > a.setEnabled(True)
>> >> > enabled = a.isEnabled()
>> >> > (..)
>> >> >
>> >> > 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?
>>
>> They'd have to be replacements not add ons.
>
> Only, iff there is a collision between those APIs, or?
> In the above example, at least, it should work to have them both,
> eventually using nasty monkey-patching.

Yes, but it isn't a typical example. Qt tends to use setThing() and
thing(), so the getter method would be incompatible with the property name.

Phil
_______________________________________________
PyQt mailing list    [hidden email]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt