From: rwgk_at_[hidden]
Date: 2001-06-25 17:02:32
Your problem looks somewhat familiar to me. What I did in
cross_module.hpp is to "artificially" change the signatures
of the C++ functions. For example:
In your module A:
string category(bool dummy = false) { return "A"; }
In your module B:
string category(int dummy = 0) { return "B"; }
This way, even if the two functions live in the same (linker)
namespace, they are still distinguishable.
If you have many modules, keeping track of what type is
used as a dummy parameter in which module could be a bit
cumbersome. Here is an entirely untested idea for a more
general approach:
namespace { struct dummy_parameter {}; }
string category(dummy_parameter = dummy_parameter()) {
return "A";
}
The compiler should create a unique identifier for the
anonymous namespace. Then you hijack this to create
a unique signature for your category function.
If you try this, please let me know how it goes.
Ralf
--- In boost_at_y..., Karl MacMillan <karlmac_at_p...> wrote:
> We're developing a interactive system involving a number of separate
> boost::python "plugins". Each plugin contains a function "category
()"
> at the module level that returns a string defining the menu that the
> plugin should be added to at run-time.
>
> string category() { return "MyCategory"; }
> ...
> ====
> python::module_builder mPlugin("plugin");
> mPlugin.def(category, "category");
> ====
>
> This approach works great when compiling for Python 2.0, but with
Python
> 1.5.2, the category function is the same for all plugins that get
imported
> (it's the category function from the first module that is imported.)
>
> ==== (Python session)
> >>> import plugina
> >>> plugina.category()
> 'CategoryA'
> >>> import pluginb
> >>> pluginb.category()
> 'CategoryA'
> ==== (New python session)
> >>> import pluginb
> >>> pluginb.category()
> 'CategoryB'
> >>> import plugina
> >>> plugina.category()
> 'CategoryB'
> ====
>
> My apologies if this is a known issue. I was unable to find
reference to
> this on the mailing list. It's one of our design requirements that
this
> works for Python1.5.2 and 2.x. We would prefer not to resort to
naming
> functions like plugina_category(), but if that's the only way... It
> just doesn't seem to fit with how Python namespaces generally
work. Any
> suggestions/workarounds? I have tried embedding the function in a
small
> class, and it doesn't work.
>
> Thanks!
>
> Karl
>
> _____________________________________________________
> | Karl W. MacMillan |
> | Computer Music Department |
> | Peabody Institute of the Johns Hopkins University |
> | karlmac_at_p... |
> | mambo.peabody.jhu.edu/~karlmac |
> -----------------------------------------------------