python-extensions

I have a Python project with many sub-modules that I package up with distutils. I would like to build some Python extensions in C to live in some of these sub-modules but I don't understand how to get the Python extension to live in a submodule. What follows is the simplest example of what I'm looking for: Here is my Python extension c_extension.c : #include <Python.h> static PyObject * get_answer(PyObject *self, PyObject *args) { return Py_BuildValue("i", 42); } static PyMethodDef Methods[] = { {"get_answer", get_answer, METH_VARARGS, "The meaning of life."}, {NULL, NULL, 0, NULL} };

I have been trying to install Cython for Python 2.7 on my Window 7 system. In particular, I prefer everything in 64 bits. (In case you wonder, I need Cython because Cython is one of the components I need for another package for some specialized numerical analysis. And x64 is potentially an advantage for storage of large data sets.) So I downloaded the x64 Python 2.7 from the official website. Got Cython from Christoph Gohlke . The amd64 version for Python 2.7 of course. Before I installed, I added Python 2.7 into the registry with the .reg file found in Joe DF's answer here . Afterwards, I

Say I have my object layout defined as: typedef struct { PyObject_HEAD // Other stuff... } pyfoo; ...and my type definition: static PyTypeObject pyfoo_T = { PyObject_HEAD_INIT(NULL) // ... pyfoo_new, }; How do I create a new instance of pyfoo somewhere within my C extension? Call PyObject_New() , followed by PyObject_Init() . EDIT: The best way is to call the class object, just like in Python itself: /* Pass two arguments, a string and an int. */ PyObject *argList = Py_BuildValue("si", "hello", 42); /* Call the class object. */ PyObject *obj = PyObject_CallObject((PyObject *) &pyfoo_T, argList

We've been long-time fans of pylint . Its static analysis has become a critical part of all our python projects and has saved tons of time chasing obscure bugs. But after upgrading from 1.3 -> 1.4, almost all compiled c extensions result in E1101(no-member) errors. Projects that previously run perfectly clean through pylint 1.3 now complain about almost every C extension member with E1101. We've been forced to disable E1101 errors, but this materially detracts from the usefulness of pylint . For example, this perfectly valid use of the lxml package r"""valid.py: demonstrate pylint 1.4 error"""