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 _______________________________________________ PyKDE mailing list PyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde