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

- Robert

[1] http://wiki.cython.org/enhancements/distutils_preprocessing

_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to