Francesc Alted wrote:
that having a small core with the "glue" functionality between numarray objects and 3rd party extensions in C (or SWIG, Pyrex or whatever) can be a good thing (until numarray is in the Standard Library).
That way, people interested in supporting numarray objects in their extensions has only to install this small core (or even include it as part of the extension).
I think that's a fabulous idea, but I have no idea how hard it would be. There would still be the problem of keeping versions in-sync. If I distributed my package with the glue code, it would only work on installations using the same version of Numeric (or NumArray, I suppose) Thanks to all who have commented on my post. These are some ideas I now have based on your comments:
Use the Python C-API and string literals as the basis for the interface. I think the steps are something like this:
1. Import "Numeric". (PyImport_ImportModule)
2. Get the module dictionary. (PyModule_GetDict)
3. Get "array" out of the dictionary. (PyDict_GetItemString)
4. Call "isinstance" on Numeric.array and the object. (PyObject_IsInstance)
OK, so now I can know, at runtime, whether Numeric has been imported.
But... It's not clear to me that knowing an object is an array will help since getting data elements still has to be done fast, and that seems hard to do without knowing the arrayobject struct.
Exactly. that's my whole problem. However, I have an idea about this. If I do the above test, I can now put all the Numeric specific code into a conditional, so it would only get called in Numeric were imported. My idea is that I could make sure Numeric was around at compile time, so I could use all the Numeric API to access the array data, but it wouldn't have to be installed at runtime, as none of the Numeric calls would be executed if Numeric hadn't been imported. Would this work, or would the system try to load the .dll or .so or whatever even if the calls weren't executed? All that being said, Tim Hochberg has mentioned that when he first made wxPython DCs work with Numeric Arrays,( sorry I didn't give him credit before, I had forgotten who did that, thanks Tim ) he did some timing and discovered that the the overhead of the drawing calls was substantially larger than the overhead of the indexing anyway, so speedin up that process couldn't make much difference. My timing indicated something different, but I'm using Linux/wxGTK/X11, and I think the drawing calls return after the message has been sent to X, but X may not have completed the actual drawing yet. This means that I'm not timing the whole process, and if I did, I might not see such a difference. I did some tests with 100,000 points, and found that I could see the difference with a List and Array, and the List was about twice as fast. Drawing rectangles, however, I can't see the difference. So, I think I'll probably shelve this for the moment, and concentrate on getting all the drawing shapes supported by DrawXXXList methods. Thanks for all your input. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov