Robert Bradshaw wrote: > On Jun 27, 2009, at 1:02 AM, Dag Sverre Seljebotn wrote: > >> Just a quick note that in the gsoc-kurt branch I've implemented this: >> >> from UtilityCode import CythonUtilityCode >> >> ... >> env.use_utility_code(foo) # only on env. currently, not code. >> >> >> foo = CythonUtilityCode(u""" >> >> class __Pyx_UtilClass: >> pass >> >> cdef int __Pyx_UtilityFunction(int arg): >> return arg * 2 >> >> """) >> >> Now, this will cause __Pyx_UtilityFunction to be dumped into the >> final C >> file, and the type descriptor to be called __Pyx_UtilClass (i.e. name >> mangling is dropped in some important cases). >> >> The details might change around a bit, this is just a note to say I've >> done it, so that noone else starts on something similar. > > I'm not opposed to this. > > Eventually we may want to consider grouping such code into a central > Cython module, or at least .h file (for multi-file compilation) as > there is a lot of redundancy between modules with all the utility > code produced.
The same thoughts did indeed occur to me. However it is strictly orthogonal to this -- utility code written in C has the same problem. And we can just set up another pipeline to have Cython dump such an .h file from existing utility code declarations. (Another completely orthogonal thing would be to move utility code to resource files for easier editing.) As for whether it should be done -- do you know if e.g. Sage builds are IO bound? If not then a header file itself won't help, you need to change the build (seperately compiled .c file, or preprocessed header files). A "Cython standard library" Python module is an interesting thought, however I think the versioning problems are too big at the moment. -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
