Jason Roberts wrote:
I recall a recent discussion regarding an "ABI breakage" with numpy 1.4.
yup -- that's it. IN short:
numpy 1.4.0 was released without the devs realizing that the ABI had
broken (or hadn't realized how many problems it would cause). It was
decided to pull that release, and instead release a 1.4.1 that didn't
break the ABI, and later on release one that did -- maybe 2.0. I think
1.4.1 is in "release candidate" stage as I write.
Given all that, I'm surprised that Entought has been released with 1.4.0
-- are you sure it came that way?
GDAL python *should* be able to use a later version of numpy than it was
built for, it's only the python side of the interface that it cares about
really? I thought it build numy arrays directly in C code? Or is is
using the "Array Protocal", in whihc case you're right, it shouldn't
care about the ABI.
Which reminds me -- this is actually a good argument fo why we should
all use the PEP 3118 extended buffer protocol, rather than the numpy API
directly, for extension modules ( at least when older python's don't
need to be supported)
Is it possible that when you use GDAL with Enthought that you've loaded
two incompatible numpys?
If you are including the GDAL framework python folder in the Enthought
python path, then numpy 1.3 is also available from there.
Sure, but if you are using other numpy-using packages together with
GDAL, you'll need to on;ly use one numpy (well, you could probably
kludge around it, but it would be ugly...)
I'd wait for/ask Enthought to release a numpy1.4.1 version of EPD, or
use EPD 5.1
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
[email protected]
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
