[PyKDE] exported symbols - all or none?

[Anthony Heading]

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.

> 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?   Even more simply, is it unreasonable
to want to call  sipGetAPI("qt")?   From that, I could chase all
the function pointers I need.

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

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.

Rgds

Anthony

This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market prices,
data and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein 
do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries 
and affiliates