On Apr 11, 2006, at 9:24 PM, Bob Ippolito wrote: > > On Apr 11, 2006, at 6:46 PM, William Kyngesburye wrote: > >> I just ran into an odd and annoying problem - I'm building a Python >> library/extension thing for a package (MapServer) and have a library >> weak-linked (it's to a non-open source product, this is so others >> don't have to install that if they don't need it and I don't have to >> build multiple versions...). Python's import seems to ignore that, I >> suspect it's doing it's own library loading thing and checking all >> symbols or something. >> >> Is this normal? Is there a way to make Python NOT do it? Or am I >> stuck with it? > > I'm not entirely sure, I haven't tried it. It uses these NSModule > flags to load extensions: > NSLINKMODULE_OPTION_BINDNOW > NSLINKMODULE_OPTION_RETURN_ON_ERROR > NSLINKMODULE_OPTION_PRIVATE > > I don't believe that any of those options would defeat weak > linking, though. > > You might have to find the library at runtime with the dyld or dl > APIs and it use that way. Or strong-link to it in a separate > extension that's only loaded if the library is detected. > It would be nice if MapServer had a simple plugin mechanism. It's supposedly there, just not documented yet.
On Apr 11, 2006, at 9:54 PM, Saggau wrote: > One way to say what I'm thinking: > > There might be another way around this. It's another way of using > two modules, which might not be desirable, but not quite the "two > versions of the same thing, one with expanded functionality" type. > Instead, it's "Two different (and more basic/plain-Jane) library > wrappers, one wrapping just the third party code functionality and > one wrapping just my code functionality." You can then test for > the existence of the third party code wrapper module and make your > python code behave accordingly. > > Another way: > > You could build one wrapper module that is only the third party > stuff and one that is only your code. Then you could use two > imports in your python code, setting a variable or just testing > whether to use the "with extras" version of your python code or the > "stripped down" version. That way, you can ship either load both > bundles or the one bundle depending on what the user's system has. > Am I making any sense? I suspect not. > I understand what you're saying, I'm just not enough of a programmer to do such a thing. > My-big-architectural-question (TM) is: > > If you know you're either going to have to deal with ifndef etc etc > in your big module code or the equivalent test to see if the little > third party module is loaded in your python code. Either way, > you'll have to adjust what you're doing somewhere in code. I have > found, with the caveat that I have limited experience with this, > that writing multiple very simple and low-level loadable bundles / > libraries with a thimbleful of functionality in each and letting > python be happily dynamic about what gets imported is easier than > trying to do the "I need to test if I can use this library or not" > in a big loadable bundle / library. > > In other words, I know where I would rather write my most dynamic > code. Python. :) It's just easier to do there and I'm lazy. > For those that use the python version of MapServer, they would not use the functionality in their python code of the extra optional external library if they don't need it. I know, kinda fragile. But it works well enough in the CGI and PHP versions. I guess I should just figure out the MapServer plugin thing. I was hoping I could wait until some documentation was written. ----- William Kyngesburye <[EMAIL PROTECTED]> http://www.kyngchaos.com/ All generalizations are dangerous, even this one. _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
