| ★ wanayoo — archive 1999 https://mail.python.org/pipermail/pythonmac-sig/2002-February/005133.html | Nouvelle recherche | Portail wanayoo |
On Wednesday, February 13, 2002, at 10:37 , Manoj Plakal wrote: > Hi Jack, > > Yes, this is the first time I'm seeing this patch. > > 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? 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. > > 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. 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. -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -