[PyKDE] exported symbols - all or none?

[Phil Thompson]

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 
and method.

> > 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 
versions.

> > 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?

Phil