[PyKDE] QString in PyQt4 - Request for Comments

[David Boddie]

On Fri, 21 Oct 2005 07:21:46, Patrick K. O'Brien wrote:

> Phil Thompson wrote:
> > 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.
>
> I agree with you, Phil.  If you look at wxPython you'll see that there
> have been a number of attempts to add a more Pythonic layer over
> wxPython, none of which have really succeeded in any significant way.

That may be so, but what I've heard about wxPython makes me think that the
reasons for this lack of success (if that is the case) is different to any
problems that a two layer Pythonic wrapper for PyQt might face.

My impression is that there are/were competing Pythonic wrappers for
wxPython, some of which are perceived as less complete than others, and
the resemblance of the wxPython API to the wxWidgets API makes it less
attractive to build on than it would be to build on top of a straight set
of Qt bindings.

> I think its unrealistic to think that a separate API could be created on
> top of PyQt that would actually gain enough support from the community
> to be something that large numbers of developers would be willing to
> take a chance on.  Nobody wants to invest in an API that might not have
> a future.  I know I feel that way.

That's may be why some people aren't sure whether they should use wxPython
or Wax. It's worth noting that Wax was represented in the Google Summer of
Code programme, so there is some support for that approach.

> > 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.
>
> Again, I agree.  And while I'm sympathetic to the C++ programmers who
> would like to see the same API when they work in Python, I'm more
> sympathetic to the Python programmers who find C++ to be strange,
> incomprehensible, or simply painful.

I'm sympathetic, too. I'm just looking for some level of continuity
between the two languages. Some changes might just lead to confusion.

> I think serious C++ programmers would have a smaller conceptual burden if
> they had to switch to a more Pythonic API when they work in Python, than
> if Python programmers had to know a bit about C++ when they work with
> PyQt.  Again, the same thing happens in wxPython - the vast majority of
> Python programmers have no desire whatsoever to have to deal with concepts
> from C++. 

That may be so, but you can't completely isolate programmers from non-
Pythonic concepts. There are restrictions due to the type system that
you can't ignore.

For example, you could map QList-based containers to Python lists and
provide a Pythonic iterator interface for them, but you still have to
ensure that they each item in the list has the same type if you want
to pass it back to C++ reliably. Some of these restrictions also help
to improve performance or memory usage at the cost of flexibility.

There are other features that are probably very strange from the
perspective of a Python developer, and there are features that are
common to Qt and the Python standard library. That doesn't necessarily
mean that the bindings need to be more Pythonic in those areas.

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

Personally, I think it doesn't make sense for Python developers to have to
deal with "const", pointer or reference notation.

However, you are communicating with C++, and the interfaces are defined in
terms of non-Python types. Declaring types isn't a natural thing in Python,
and many people are going to fall back on the documentation for this, so
introducing another convention might actually make it more difficult for
some developers. You can provide functions to convert between notations,
but you could implement something like this on top of the existing scheme.

The above probably seems very unfocused. I'm not against the idea of
Pythonic bindings in principle, though I am aware that making things easier
for some developers (maybe the majority in the future) can make things
difficult for others.

David