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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4