[PyKDE] Dependency on sip.pyd
phil at riverbankcomputing.co.uk
Sat Nov 11 01:30:39 GMT 2006
On Friday 10 November 2006 7:44 pm, Giovanni Bajo wrote:
> Phil Thompson wrote:
> >> What I would like to obtain is that modules generated by SIP do not
> >> depend on an external module (sip.pyd). This is technically possible
> >> of course, it's just that SIP was designed in a different way.
> >>> sip.pyd is a Python extension module - it is not a library and it is
> >>> not linked against.
> >> This is the current design, I'm asking to add an option to change
> >> this.
> >>> You can build it statically and have it built in
> >>> to your Python interpreter - same for PyQt (though I don't test
> >>> this). So you could create a project specific interpreter.
> >> To be clear, I'm not speaking of embedding sip.pyd in python.dll as a
> >> builtin module. I'm speaking of totally *removing* sip.pyd as a
> >> module, and just "put" all the necessary code within my own
> >> extension module created by SIP.
> > ...just like SIP v0.1 used to work.
> You mean just like any other binding tool does? I don't see boost::python
> or SWIG generating a module which depends on another one. You even list the
> fact that generated modules are directly importable without a Python
> wrapper (as those generated by SWIG) as a feature. I don't see why making
> them not depend on an external module is not progress.
Progress, yes. Possible, yes. Worth the effort? I'm not convinced.
A genuine question (because I don't know the answer) - do Boost and SWIG
support the wrapping of a C++ class hierarchy across multiple modules? Do
they support the ability for somebody else to wrap 3rd party libraries that
derive from the wrapped C++ library? That (to me anyway) is SIP's most
> > No, I'm not going to do that.
> I explained real effective troubles which are caused by the current design.
> Binary dependency *is* a bad headache which seriously affects the usage of
> SIP, and its choice as a primary binding tool within a company. I would
> appreciate if you could explain your position.
The first versions of SIP generated all code in-line. The common code was
broken out into a separate library/module (I think) when I wanted to separate
PyQt and PyKDE. By "library/module" I mean that the SIP code was implemented
as a separate Python extension module, but also linked against by the
generated code. This was the design of SIP v3.
That design broke all the rules of Python extension modules. It also wouldn't
work on MacOS (because modules and libraries are compiled with different
flags). SIP v4 fixed those problems.
The sip module isn't just a "library" of code common to SIP generated modules.
It handles the exporting of lots of code from (for example) PyQt to PyKDE or
PyQwt without PyQt being aware of the existence of PyKDE, PyQwt etc. I'm sure
it would be possible to implement that without a sip module, but the obvious
(aka easiest) solution is to have a central module that acts as a broker for
all the inter-module communications that are required.
If Boost and SWIG implement this without a central module then I bow to their
superior architecture. If they don't support this functionality...then I
don't bow. (I think the correct expression is that "I fart in your general
I appreciate your problem is real, but this solution isn't the right one.
More information about the PyQt