"PB" == Paul Barrett <Barrett@stsci.edu> writes:
PB> .size (in bytes): e.g. 4, 8, etc.
"element size?"
PB> How about item_size? OK.
No, it is not what I meant. Reading your answer I'd say that I wouldn't see the need for an Array. We only need a data buffer and an ArrayView. If there are two parts of the functionality, it is much cleaner to make the cut in an orthogonal way.
PB> I just don't see what you are getting at here! What attributes PB> does your Array have, if it doesn't have a shape or type? A piece of memory. It needs nothing more. A buffer[1]. You'd always need an ArrayView. The Arrayview contains information like dimensions, strides, data type, endianness. Making a new _view_ would consist of making a new ArrayView, and pointing its data object to the same data array. Making a new _copy_ would consist of making a new ArrayView, and marking the "copy-on-write" features (however that needs to be implemented, I have never done that. Does it involve weak references?). Different Views on the same data can even have different data types: e.g. character and byte, or even floating point and integer (I am a happy user of the fortran EQUIVALENCE statement that way too). The speed up by re-use of temporary arrays becomes very easy this way too: one can even re-use a floating point data array as integer result if the reference count of both the data array and its (only) view is one. [1] Could the python buffer interface be used as a pre-existing implementation here? Would that make it possible to implement Array.append()? I don't always know beforehand how large my numeric arrays will become. Rob -- ===== rob@hooft.net http://www.hooft.net/people/rob/ ===== ===== R&D, Nonius BV, Delft http://www.nonius.nl/ ===== ===== PGPid 0xFA19277D ========================== Use Linux! =========