[PyKDE] exported symbols - all or none?
phil at riverbankcomputing.co.uk
Wed Apr 27 22:30:35 BST 2005
On Wednesday 27 April 2005 7:40 pm, Anthony Heading wrote:
> On Wed, Apr 27, 2005 at 08:42:34AM +0100, Phil Thompson wrote:
> > And the bolted on code isn't called from Python?
> It's not wrapped via SIP.
But is it called from Python? If it is then why not use SIP to create a module
with the required functionality?
SIP doesn't have to wrap a C++ library - you can use it to write standalone
modules. All you need to do is to provide handwritten code for each function
> > A function could be added to do what you want - but it would still
> > require that you imported the modules that defined the classes you were
> > interested in.
> I don't understand that. The sip module could theoretically broker any
> information between modules, no?
Yes, so long as it knew about the modules, ie. that they had been imported.
> Even more simply, is it unreasonable
> to want to call sipGetAPI("qt")? From that, I could chase all
> the function pointers I need.
The problem with that is that I would have to publish the data structure that
represents the API. At the moment it is internal and I do change it between
> > Python modules are not shared libraries that you should link against -
> > they are more like plugins. On most platforms libraries and plugins are
> > implemented identically. When I first designed SIP I didn't understand
> > the distinction and used the generated module as both a shared library
> > and a plugin - which meant that it didn't work on platforms that
> > implemented them differently. SIP 4 corrected this design error.
> Understand. But %Import'ing e.g. the qt module generates a lot of files,
> enough to extend the qt class hierararchy, and seems a lot of baggage just
> to get hold of some function pointers.
It generates a lot of files, but those don't generate any code. Those files
define how a module accesses the API of those modules it %Imports.
> But if I understand now, there's an implicit rule that the only C++ code
> that can interact with a SIP module is in a derived module. I'm not
> sure why that rule is imposed, because at a Python level any C++ code
> can call PyImport_ImportModule (just as sip_api_export_module is doing)
> to access a module without any requirement to inherit from it. And
> that's a different constraint from the plugin/library linker distinction.
Yes - the constraint is a result of the module API not being published.
I'm quite happy to add stuff to the documented API (either at the C/C++ level
or within the sip module) if it makes sense and is maintainable.
Can you give me a real-life example of what you are trying to do?
More information about the PyQt