In petsc4py, I've just implemented support for compose()/query() in my base Object class. However, I wanted to implement query() in such a way that 'dynamic_cast' (in the C++ sense, i.e, downcast) the composed PETSc object and return to Python code an instance of the appropriate Python type. Then, if you compose() a Mat, then query() will return a Mat.
I manages all this inside a private python dictionary mapping PetscCookie -> Python type. Of course, this required to make sure that ALL PetscXXXInitializePackage() have been called before adding stuff to my dict. All is working fine; moreover, this machinery is also being used in slepc4py and tao4py (yes, I have those...), then after importing slepc4py or tao4py, the dictionary is populated as appropriate. Then, the question are: Do this approach sound good enough? Is it too much hackery? Can I relly in the long future that this approach will always work? BTW, now I have a clear use case for initalizing all the XXX_COOKIE's to 0 in core PETSc. This will really help me to spot package initialization problems. In fact, I had to manage some of those problems in petsc-2.3.2, petsc-2.3.3 and tao-1.9 . PS: The renaming DA_COOKIE -> DM_COOKIE does not play well with all this, but I do not care about it right now. -- Lisandro Dalc?n --------------- Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC) Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC) Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET) PTLC - G?emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594
