Attempting to mix py::module_local and non-module_local classes results in some unexpected/undesirable behaviour: - if a class is registered non-local by some other module, a later attempt to register it locally fails. It doesn't need to: it is perfectly acceptable for the local registration to simply override the external global registration. - going the other way (i.e. module `A` registers a type `T` locally, then `B` registers the same type `T` globally) causes a more serious issue: `A.T`'s constructors no longer work because the `self` argument gets converted to a `B.T`, which then fails to resolve. Changing the cast precedence to prefer local over global fixes this and makes it work more consistently, regardless of module load order.
| Name |
Last commit
|
Last Update |
|---|---|---|
| .. | ||
| _static | Loading commit data... | |
| advanced | Loading commit data... | |
| Doxyfile | Loading commit data... | |
| Makefile | Loading commit data... | |
| basics.rst | Loading commit data... | |
| benchmark.py | Loading commit data... | |
| benchmark.rst | Loading commit data... | |
| changelog.rst | Loading commit data... | |
| classes.rst | Loading commit data... | |
| compiling.rst | Loading commit data... | |
| conf.py | Loading commit data... | |
| faq.rst | Loading commit data... | |
| index.rst | Loading commit data... | |
| intro.rst | Loading commit data... | |
| limitations.rst | Loading commit data... | |
| pybind11-logo.png | Loading commit data... | |
| pybind11_vs_boost_python1.png | Loading commit data... | |
| pybind11_vs_boost_python1.svg | Loading commit data... | |
| pybind11_vs_boost_python2.png | Loading commit data... | |
| pybind11_vs_boost_python2.svg | Loading commit data... | |
| reference.rst | Loading commit data... | |
| release.rst | Loading commit data... | |
| requirements.txt | Loading commit data... |