On 2010-06-26 02:51 , Robert Bradshaw wrote: > On Jun 26, 2010, at 12:47 AM, Robert Kern wrote: > >> On 2010-06-26 02:31 , Robert Bradshaw wrote:
>>> If we do change, it should probably be to .cy, .cyd, and .cyi (the >>> latter simply being a convention). However, I'm not convinced (or >>> unconvinced) the gain would be worth the resulting confusion. >>> Gracefully handling build tools is a good argument, but in terms of >>> that specifically I would like to see us moving towards handling the >>> Cython -> C step ourselves and letting distutils only worry about >>> the >>> C -> shared object library step [1] (and a robust pyximport or even >>> inline/decorated functions in pure Python files). >> >> I'm afraid that doesn't help other build tools, like >> numpy.distutils. We need to >> know whether a .pyx file is a Pyrex file or a Cython file before we >> can import >> Pyrex or Cython to let them do the transformations. A .cy extension >> would be a >> huge help. > > The point is that numpy.distutils wouldn't have to know about Cython > at all--it would just be handed a bunch of .c files to make extensions > out of. This way we wouldn't have to make any of the many distutils > variants Cython-aware. cythonize() wouldn't work with a numpy.distutils-using setup.py. We don't pass the list of Extensions explicitly. There are also other non-distutils build tools, like SCons, waf, and yaku, that would be able to use the .cy extension to distinguish Pyrex files from Cython files. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
