[PyKDE] exported symbols - all or none?

[Phil Thompson]

On Wednesday 27 April 2005 3:30 am, Anthony Heading wrote:
> On Tue, Apr 26, 2005 at 09:22:31AM +0100, Phil Thompson wrote:
> > Don't do this - it won't work. Modules now build standalone - you do not
> > link them against modules that are imported.
>
> Well, it works ok.  But am happy to try to do it the right way instead.
>
> > SIP v4 modules only export one symbol per module, ie. they follow the
> > rules for modules. You can still refer to things like sipType_QSomething
> > - those references are resolved through other means and not through the
> > linker.
>
> The only way I can see to do this is to build a sip module which imports
> the classes that I need to access.  It looks like that gives the module
> handles to the API structure for each of the dependent modules.

Yes, that's the whole point of the %Import directive.

> Unless I do that, I'm stuck, no?  My problem is that I have some
> bolted-on code which was using the sip conversion functions to
> e.g. access the underlying Qt classes given a Python handle.
> None of the SIP api functions appear to provide for that.

And the bolted on code isn't called from Python?

> I wondered if sipMapStringToClass might be what I was looking
> for, but that seems to require a class map to be passed in?
> Am I misunderstanding if I were hoping simply to call
>     sipMapStringToClass("qt.QPen")
> or something similar?  Surely a global lookup is a reasonable
> thing given the names must be unique?

sipMapStringToClass() is just a convenience wrapper around a call to 
bsearch().

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. And if you did that, you could just refer to the type objects explicitly 
by name.

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.

Phil