[Pyrex] array setting and math function annoyance

[Arc Riley]

> It's always better to improve things than to branch for trivial changes


I agree.  It's troubling to see this proliferation of project-specific Pyrex
branches each with only minor changes.

In contrast, however, we've been at the mercy of Greg to decide when to
accept patches, his available time to rewrite them, then later release, and
finally for a new release to be packaged by distros.  I understand this is a
frustration you guys had too, behind your reason to form Cython, but if we
used Cython we would be in the same situation with you than we are with
Pyrex.

We're not interested in the language pre-processor politics, we've stayed
out of them so far, but given all our logistics we really need greater
control over that part of our own project.


You can't just ignore the most obvious way to build a C extension for Python
> (i.e. using distutils), and then come and complain that your hand-written
> setup doesn't work.


Oh, we're using Python's distutils to build the C source.

That 100 lines in our setup.py is a workaround for Pyrex.Distutils failure
of detecting source changes and rebuilding .c files only when necessary.
That part would be better generalized and in Distutils rather than in our
setup.py since any project could take advantage of it

The rest is to generate the list of libraries for distutils to link
against.  As far as I'm aware this is required for distutils regardless -
how's it to know GLEW is called libglew32 on Windows?


improve Cython's distutils helper (build_ext.py) to handle the problem of
> calculating dependencies better.


That's what we're looking at, yes.

I think the most pragmatic solution for us right now is a branch, given our
release time table and Cython's level of recent commit activity, and that
these changes will undoubtedly require discussion.

We'll of course provide patches.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.copyleft.no/pipermail/pyrex/attachments/20080314/2125ca5a/attachment.html