> Cython is a very open project, and we really try to attract people who > want to > contribute, instead of creating new branches for no good reason.
The text at the top of the site should be changed from " Development of Cython is mainly motivated by the needs of SAGE" in that case :-) Cython has a much (much!) faster release cycle than Pyrex, and it has an > open > development repository (Pyrex also has one by now, BTW). Last I checked, Pyrex has a tarball of a mercurial image. This does not equate to an open development repository, IMHO. > So you can use developer versions with the fixes/features you need even > before a new release > comes out. Again, I don't want this to come across negative, but we're limited to what's been *released* and in many cases *packaged* for distros because it's a dependency to build from source. It was a pain for people when we upgraded to Pyrex 0.9.6.x since it broke compatibility with Pyrex 0.9.5.1awith all the __cinit__'s I wrote a patch so that you can do that with Cython. You will just have to > care for the dependency tracking yourself, and provide your distutils > Extension with the complete list of sources (including .pxi and .pxd > files). > Cython (or rather distutils) will then build only those extensions where > any > of the source files in that list has changed. Thank you for this, but note that it's minor compared to the various functions which search for cimports and the like. We've worked around what it builds a package as (I hope) using the full_module_name argument to compile but this is only the beginning. Setting the package directory '':'src' would, as I understand it, cause Cython to compile our extensions not as (ie) src.colors.soy.colors but as colors.soy.colors; closer, but still a no-go. Honestly I think a distutils.extension.Extension parameter for psources= (etc), treating the Pyrex/Cython/etc sources in a style akin to compiling C sources, compiling each source to a separate .c file, and appending those generated .c files to sources= is a better direction to go Is there anything in addition to my patch that you need here? Immediately, the most direct and painless solution would be to handle cimport name searching by only it's file name, rather than it's directory path, to match Pyrex's behavior. I'm a huge fan of minimizing hacks, so ideally I'd like a more direct behavior akin to the above suggestion.
_______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
