On Jun 26, 2010, at 12:47 AM, Robert Kern wrote: > On 2010-06-26 02:31 , Robert Bradshaw wrote: >> On Jun 24, 2010, at 10:09 AM, Dag Sverre Seljebotn wrote: >> >>> Cython files are called .pyx files for historical reasons: For a >>> long >>> time Cython was simply smaller patches on top of Pyrex. This is not >>> longer true. I don't believe we would honestly recommend to anyone >>> that >>> they maintain codebases that should be buildable on both compilers. >>> (That it is easy to convert a Pyrex project to a Cython project is >>> another story.) >> >> I've always thought of pyx as meaning "python extension" more than >> Pyrex. >> >>> While the .pyx extension will obviously stick with us for many years >>> to >>> come, I'm proposing that we add support for a .cy extension as well, >>> and >>> change the documentation to use this. They'll be completely >>> interchangeable, almost nothing in the Cython codebase should know >>> the >>> difference (and I imagine that Sage and lxml would stick to pyx >>> for a >>> long time). >>> >>> This is simply to be a good citizen. Build systems rely on >>> extensions to >>> invoke the proper tool, and it would then be possible for SCons, >>> waf, >>> CMake etc. to include default builders for both Cython and Pyrex >>> without >>> any conflicts (if you want to use such tools, you simply use the .cy >>> extension -- if you already use .pyx you obviously already have a >>> build >>> system set up for that). It would even be possible to mix Cython and >>> Pyrex in the same project (e.g. with distutils...). Not that that >>> is a >>> likely situation, but it seems less arrogant with respect to Pyrex >>> to >>> use our own suffix rather than patching away Pyrex support in the >>> build >>> tools. >>> >>> (setuptools already hardwires .pyx to Pyrex, for instance). >> >> 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. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
