https://svn.boost.org/trac10/ticket/3653 <p> from a thread on the c++-sig list titled "dynamic compile and to-Python converter..." </p> <p> The 'worst' and most common scenario is, precisely put: more than one python extension module over which we have no control has wrapped type T. We need to use them simultaneously. For instance, here are two modules that both wrap vector&lt;double&gt;. With assertions enabled, this happens: </p> <blockquote class="citation"> <blockquote class="citation"> <blockquote class="citation"> <p> import converter_collisions1_ext import converter_collisions2_ext </p> </blockquote> </blockquote> </blockquote> <p> python: /home/troy/Projects/boost/src/libs/python/src/converter/registry.cpp:212: void boost::python::converter::registry::insert(<a class="missing wiki">PyObject</a>* (*)(const void*), boost::python::type_info, const <a class="missing wiki">PyTypeObject</a>* (*)()): Assertion `slot-&gt;m_to_python == 0' failed. zsh: abort python </p> <p> delightfully, without assertions there is only a warning: </p> <blockquote class="citation"> <blockquote class="citation"> <blockquote class="citation"> <p> import converter_collisions1_ext import converter_collisions2_ext </p> </blockquote> </blockquote> </blockquote> <p> <span class="underline">main__:1: <a class="missing wiki">RuntimeWarning</a>: to-Python converter for std::vector&lt;double, std::allocator&lt;double&gt; &gt; already registered; second conversion method ignored. </span></p> <p> So one resolution is to remove the 'assert' that triggers this crash and leave the semantics as-is: second and later converter registrations are warned about and ignored. I'm simply suggesting we give the user more control over this behavior, because in a number of situations (it is up to the user to determine what they are) such control would be useful. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/3653 Trac 1.4.3