Hi, Ignore this please. The answer was staring me in the Cython docs: Cython ignores what’s inside the cdef extern from block; the compiler reads the correct definitions from the header file. I’ve read this many times but keep forgetting!
Sorry about that. Thanks, Samar > On Jun 5, 2025, at 10:44 AM, Samar Khatiwala <samar.khatiw...@earth.ox.ac.uk> > wrote: > > Hello, > > I’m writing a Python extension module to expose various classes, functions in > my C PETSc-based application code. I’ve taken a lot of inspiration from > petsc4py and borrowed bits of code from it. Everything works but one niggling > issue I’m facing is how to automatically inherit the data-types used to build > PETSc in my Cython code. Specifically, I want to make sure that if PETSc is > built with 64-bit ints then I use the correct type when I call my PETSc C > functions or create Numpy arrays with PyArray_SimpleNewFromData, etc. > > I tried to understand how petsc4py does it, but looking at PETSc/PETSc.pyx it > seems that PetscInt is hardwired: > > cdef extern from * nogil: > ctypedef long PetscInt > ctypedef double PetscReal > ctypedef double PetscScalar > > PetscInt is then used elsewhere Ωin petsc4py (e.g., in Mat.pyx) when calling > PETSc functions. But wouldn’t this be incompatible with the PetscInt defined > in petscsystypes.h if PETSc were built with --with-64-bit-indices? > > On the other hand, I see (sort of; the code is very complicated!) that > arraynpy.pxi correctly picks up (via numpy.h) the mappings between PETSc and > Numpy arrays and these are used in the few places where an enumerated data > type is required as an argument (e.g., in DMSwarm.pyx). > > I don’t believe there’s any incompatibility with PetscInt in petsc4py so I’m > likely missing something here. Could someone please explain how PetscInt, etc > pick up their correct values and how I can do the same in my code? > > Thanks very much! > > Best, > > Samar > > > > >
