[Python-Dev] Re: Minimal GCC/Linux shared lib + EH bug example

[Ralf W. Grosse-Kunstleve]

Mark Mitchell <mark@codesourcery.com> writes:
> That might change if the ELF/C++/etc. semantics get better in the ways
> that are being discussed, but at present, I will simply say that if
> I were going to build a Python extension module, I would do it in C,
> even though I generally find that I am more cost-effective when working
> in C++.

The traditional idea of "writing an extension" does not apply if you
work with Boost.Python. Effectively, Boost.Python is turning Python
into a scripting front-end for C++. We find this to be extremely
powerful and productive. For us there is no alternative to this
approach: we need an object oriented language in both the compiled and
the scripted layer.

Martin Loewis writes:
> Mark Mitchell <mark@codesourcery.com> writes:
> > If the rule was that, for example, all externally visible names in the
> > loaded modules had to be within namespaces that were assigned by some
> > naming authority, or otherwise consistent, then you could load modules
> > with RTLD_GLOBAL.
> > 
> > Yes, I know this is non-trivial, but if you want to use C++, it's the
> > practical solution over the medium term.
>
> That indeed is an option: with sys.setdlopenflags, the application can
> override Python's default of RTLD_LOCAL.

If this reliably solves the problem it will work for us. However, it is
not ideal that sys.setdlopenflags is a one-size-fits-all global
setting. It would be better if the user could have more fine-grained
control, e.g.  package-level control to be used in the __init__.py
files.

Ralf