Absolultely confused...

[Jeremy Moles]

Well, there's certainly no doubting that all of you are right. I guess
now I need to track down how this is happening and either fix it or
understand it so that I can explain why I'm having to work around it. :)

Many, many thanks. :)

On Thu, 2005-10-06 at 16:48 +0200, Daniel Dittmar wrote:
> Jeremy Moles wrote:
> > So, here is my relevant code:
> > 
> > 	PyArg_ParseTuple(args, "O!", &PyType_vector3d, &arg1)
> > 
> > And here ismy error message:
> > 
> > 	argument 1 must be pylf.core.vector3d, not pylf.core.vector3d
> > 
> 
> It looks as if two PyType_vector3d exist in your system
> - the one that created the object passed to your routine
> - the one in your extension code
> 
> As PyType_vector3d probably comes from a shared object/DLL
> - does your code accesses really the same shared object that is also 
> loaded by the Python interpreter? It could be that you linked with a 
> specific file, but Python loads something different from $PYTHONPATH
> - on Windows, you couldn't simply import a variable from a DLL, you had 
> to call a special routine to get the pointer
> 
> One possible portable solution: in your module initialization
> - import pylf.core
> - create an object of type vector3d
> - use your knowledge about the inner structure of Python objects and get 
> the pointer to the PyType from the object
> - store it in a module static variable TypeVector3D
> - pass that variable to PyArg_ParseTuple
> 
> Browse the Python Extension API, maybe partts or all of this are already 
> available.
> 
> There's still a problem left when pylf.core gets reloaded (rare, but 
> possible). I assume the shared object also gets reloaded, which means 
> that the type objects gets loaded to a new address and PyArg_ParseTuple 
> will complain again. I'm not sure if there is a solution to this, 
> because there still could be objects create from the old module.
> 
> Maybe you should just check the type yourself by comparing the class 
> names buried in the PyType. You could cache one or two type pointers to 
> speed this up.
> 
> Daniel