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. -- 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
