On Monday 11 September 2006 11:47, Simon Edwards wrote: > Then if I have a KDE program PyFoo that includes a Python C module (or sip > wrapper) and was developed for KDE 4.0, it will called something PyFoo2.5 > and require KDE 4.0 or later. When KDE 4.1 comes out maybe Python 2.6 is > also out, but the packager has also made a python2.5-qt and python2.5-kde > for KDE 4.1 which is enough to run the older PyFoo2.5 package. This can > only work if sip and libsip remain backwards compatible during the lifetime > of KDE4. Although not perfect, there is still a lot of compatibility to be > had without having to recompile everything everytime a new KDE and Python > come out.
> To make this possible PyKDE in KDE4 will need to support compiling to > different target Python versions. Another requirement we need to keep in > mind for KDE 4. I guess I don't understand. I'd start from Phil's point - if a new Python rev isn't binary compatible, then we'd be stuck with some version of Python for the life of KDE 4., and so would anyone who developed for PyKDE/PyQt. If you look at what's changed in Python over the life of KDE 3, that doesn't sound very appealing. What I don't understand is where the problem occurs - PyKDE will build to whatever version of Python sip and PyQt were built against, and won't build against a Python without sip and PyQt. Apps written against those in Python pretty much will only care if it's Qt/KDE 3 or Qt/KDE 4. Distributors can tailor their installations so everything works - if some 3rd party bindings need a specific sip/Python version, there's nothing to prevent that from co-existing with whatever kdebindings uses, or whatever a user compiles sip, etc against. Anything in KDE should be consistent in the Python version it uses - KDE already forces lib installs and even new Qt installs with each release. There is no libsip anymore, as far as I'm concerned - everything is in /site-packages for a specific Python version. PyKDE already requires sip later than sip 4.0 (some changes in how mapped type code is written) anyway, so current versions won't work with libsip/sip3. So all that's left is some 3rd party apps that depend on sip but aren't part of KDE and can't be handled by a distributor, and that seems to me to be a pretty small set to limit ourselves to an obsolete Python version for. Is there a concrete example of where this is or would be a problem - not PyFoo, but something real where the problem exists or will exist? Jim _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
