[Numpy-discussion] Release of scipy core beta will happen next week.
rkern at ucsd.edu
Sun Sep 25 20:00:10 CDT 2005
Gerard Vermeulen wrote:
> On Sat, 24 Sep 2005 22:51:27 -0600
> Travis Oliphant <oliphant at ee.byu.edu> wrote:
>>At the SciPy 2005 conference I announced that I was hoping to get a beta
>>of the new scipy (core) (aka Numeric3 aka Numeric Next Generation)
>>released by the end of the conference.
>>This did not happen. Some last minute features were suggested by
>>Fernando Perez that I think will be relatively easy to add and make the
>>release that much stronger.
>>Look for the beta announcement next week.
>>For the impatient, the svn server is always available:
> Hi Travis,
> when I tried a few months ago to compile one of my C++ Python modules with
> Numeric3, g++-3.4.3 choked on the line
> typedef unsigned char bool;
> in arrayobject.h, because bool is a predefined type in C++.
> I see the offending line is still in SVN (did not try to build it though).
Will this do the trick?
typedef unsigned char bool;
#define false 0
#define true 1
#endif /* __cplusplus */
> Sorry for sitting on the bug so long; the main reason is that at the time
> (I suppose it is still the case) Numeric3 does not coexist well with
> Numeric in the same Python interpreter (I remember import conflicts).
> If a typical Linux user wants to play with Numeric3, he has either to remove
> Numeric (and break possible dependencies) or build his own Python for Numeric3.
> I think that most Linux users are not going to do this and that it will take more
> than a year before distros make the move. Hence, my lack of motivation for
> reporting bugs or giving it a real try.
scipy_core does not interfere with Numeric anymore. It's installed as
scipy (so it *will* interfere with previous versions of scipy).
While we're on the subject of bugs (for reference, I'm on OS X 10.4 with
* When linking umath.so, distutils is including a bare "-l" that causes
the link to fail (gcc can't interpret the argument). I have no idea
where it's coming from. Just after the Extension object for umath.so is
created, the libraries attribute is empty, just like the other Extension
* When linking against Accelerate.framework, it can't find cblas.h . I
have a patch in scipy.distutils.system_info for that (and also to remove
the -framework arguments for compiling; they're solely linker flags).
* setup.py looks for an optimized BLAS through blas_info, but getting
lapack_info is commented out. Is this deliberate?
* Despite comment lines claiming the contrary, scipy.linalg hasn't been
converted yet. basic_lite.py tries to import lapack and flapack.
* scipy.base.limits is missing (and is used in basic_lite.py).
* Bundle the include directory in with the package itself and provide a
function somewhere that returns the appropriate directory. People
writing setup.py scripts for extension modules that use scipy_core can
then do the following:
from scipy.distutils import get_scipy_include
someext = Extension('someext', include_dirs=[get_scipy_include(),
This would help people who can't write to
sys.prefix+'/include/python2.4' and people like me who are trying to
package scipy_core into a PythonEgg (which doesn't yet support
installing header files to the canonical location).
rkern at ucsd.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
More information about the Numpy-discussion