[SciPy-dev] Is it ok to depend on ctypes for scipy code ?
Wed Jun 13 16:50:44 CDT 2007
One of the big uses for ctypes though is for calling shared libraries
that "already exist." For instance things like BLAS, LAPACK, MPI can
all be called this way. It seems like the main objection is for cases
where the shared library is not yet built. My feeling is that if
foo.so can be installed using one of the package managers or through
./configure/make/make install, it is not as big of an issue. Granted,
such a situation could possibly create a new external dependency which
might not be wanted, but the actual issue of building the .so sort of
On 6/13/07, Travis Oliphant <firstname.lastname@example.org> wrote:
> Robert Kern wrote:
> >Brian Granger wrote:
> >>>> Subject says it all. Is is ok to depends on ctypes for scipy code,
> >>>>or should the implementation be optional with a python fallback ?
> >>>I'd prefer not to depend on ctypes. More specifically, I'd prefer not to worry
> >>>about building or finding non-extension shared libraries.
> >>Given the facts that i) ctypes now comes with python2.5 and ii) that
> >>ctypes is proving itself to be extremely useful for wrapping C-code,
> >>it seems like a shame to not be able to utilize ctypes for scipy code.
> >> I do understand the issue with having dependencies on external shared
> >>libraries that need to be built. But, is there a reasonable way of
> >>addressing this problem that would open the door for using ctypes in
> >I haven't seen one, yet; otherwise, I wouldn't have made the objection.
> Robert is right. The big problem is fixing distutils to build a shared
> library. If that is fixed, then it would not be a hard thing to rely on
> ctypes for SciPy. Until that is fixed, we can't do it.
> There are several people who have started with this solution (I'm pretty
> sure it is solvable), but none of these solutions have ended up in
> distutils or numpy.distutils.
> Scipy-dev mailing list
More information about the Scipy-dev