[Pythonmac-SIG] Re: dynload_next patch - still waiting for feedback

[Marcel Prastawa]

Jack and Manoj,

First, a brief note/reminder: Steve's dynload_darwin.c have fixed most 
(all?) of the issues that some of us (or is it just me?) encountered. 
There's just a minor issue about warning messages. Oh, and there is a 
licensing issue as well, it uses some code from libdl which uses the Apple 
license. Maybe Steve could share his thoughts on this issue?

Manoj wrote:
>> My only comment: does this mean that one needs
>> to know how a module has been compiled and then
>> fiddle with sys.setdlopenflags() if necessary
>> before importing it? Isn't that a problem if you're
>> writing stuff that has to be distributed and needs
>> to import external modules not under your control?

Jack wrote:
> Yes. The sys.setdlopenflag() was added explicitly for this. If I 
> understood Marcel's comments this is good enough for VTK: apparently 
> there's some framework there that makes sure setdlopenflag() is called 
> before importing the interdependent extension modules.

Actually, VTK does not have any special framework that does this. Things 
just happened to work together when you set global imports (manually in 
Python, before actually doing the imports). Now that Manoj brought it up, 
I realize that this can be a problem.  It does give you some flexibility, 
but maybe using sys.setdlopenflags() is not such a good idea after all.

Manoj wrote:
>> Wouldn't it be better to shift the responsibility
>> to the module building phase: a change to
>> distutils which changes the link options between
>> flat or 2-level? Keep it 2-level by default,
>> and only those modules which absolutely need flat
>> can specify an extra distutils option.

Jack wrote:
> That's what I thought too, but somehow it doesn't work that way. I think 
> that for a plugin the global symbols in the plugin are in the "toplevel" 
> namespace, so if you load the plugin into the application global 
> namespace all symbols from the plugin will appear in the global namespace.
>  Symbols that the plugin references from other dynamic libraries probably 
> won't (but I didn't try this), but our real problem is the plugin initxx(
> ) routine which conflicts with the initxx() routine from a different 
> module.

To my knowledge, with two-level namespaces, we won't face any problems 
with undefined symbols and namespace clashes, even with the initxx() 
functions. Unfortunately, porting UNIX applications to OS X with two-level 
namespaces can be quite burdensome. So, if possible, I think that the 
dynamic loader should have some mechanisms to deal with flat namespace 
issues.

Marcel