[Pyrex] Cython development (was: array setting and math function annoyance)

[Arc Riley]

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.copyleft.no/pipermail/pyrex/attachments/20080314/5c17278d/attachment.html