On 10/20/05, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > James Emerton <[EMAIL PROTECTED]> wrote: > > > That's a valid point, but I don't think it needs to be a 'totally > > separate project.' I understand the potential for incompatibility > > with two versions of PyQt, but what if they had different names? They > > can still be built from the same codebase, with %Feature directives. > > I believe a Python-only implementation would be easier to work on. See also > the > mail by David Bobble with which I totally agree.
This depends on where you draw the line. A total Pythonic implementation of Qt is infeasible. The PyQt community is not large enough to develop a stable and mature API. I do not mean to imply a lack of ability, simply a lack of manpower. The Qt 3.3 docs list 3626 unique method names, with many of them appearing in multiple classes. That's an awful lot of maintenance! I'm far more interested in an API that does not introduce redundant types. Implementing this kind of type conversion directly in Python is both ugly and slow. It requires the implementation to wrap every method that returns a type that should be converted. SIP already has a facility to deal with this: %MappedType. This keeps the documentation problem out of the way as well; provide a list of classes and their Python equivalent. With a little effort, someone could even assemble a post-processor that mutates the Qt/C++ docs into their Python equivalent. If someone wants to take on the task of implementing the truly Pythonic API, they will at least not have to worry about all those wonky Qt/C++ types. James _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
