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.
the Pseudo-broken pythonic way to say it:
<code> #sorta
try:
import MyThirdPartyModuleWrapper #corresponding to MyThirdPartyModule.so
import MyPythonCodeThatUsesTheThirdPartyModuleWrapper as MyPythonCode
except ImportError:
import MyPythonCodeThatDoesntUseTheThirdPartyModule as MyPythonCode
</code>
in both MyPythonCodeThatDoesntUseTheThirdPartyModule.py and MyPythonCodeThatUsesTheThirdPartyModuleWrapper.py you would:
<code> #sorta
import MyCodeThatIsntThirdParty #corresponding to MyCodeThatIsntThirdParty.so
</code>
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.
Cheers,
Jonathan Saggau
PS - This is the really long version of what Bob just said here:
"Or strong-link to it in a separate extension that's only loaded if the library is detected."
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig