Thu Nov 16 16:52:29 CST 2006
consumer could determine most everything it needed to know about the data.
Simple routines could determine things like iscontiguous(bm), iscarray(bm)
or isfortran(bm). I expect libraries like wxPython or PIL could punt
(raise an exception) when the water gets too deep.
It also doesn't prohibit other attributes from being added. Just because
an N-Dimensional array described it's itemtype using the struct module
typecodes doesn't mean that it couldn't implement more sophisticated typing
hierarchies with a different attribute.
There are a few commonly used types like "long double" which are not
supported by the struct module, but this could be addressed with a little
discussion. Also you might want a "bit" or "Object" typecode for tightly
packed mask arrays and Object arrays.
The names could be argued about, and something like:
would really bring home the notion that the attributes are a description of
what it means to participate in an N-Dimensional array protocol. Plus
names this long and ugly are unlikely to step on the existing attributes
already in use by Numeric3 and Numarray. :-)
Anyway, I proposed this a long time ago, but the belief was that one of the
standard array packages would make it into the core very soon. With a
standard array library in the core, there wouldn't be as much need for
general interoperability like this. Everyone could just use the standard.
Maybe that position would change now that Numeric3 and Numarray both look
to have long futures. Even if one package made it in, the other is likely
to live on. I personally think the competition is a good thing. We don't
need to have only one array package to get interoperability.
I would definitely like to see the Python core acquire a full fledged array
package like Numeric3 or Numarray. When I log onto a new Linux or MacOS
machine, the array package would just be there. No installs, no hassle.
But I still think a simple community agreed upon set of attributes like
this would be a good idea.
--- Peter Verveer <verveer at embl.de> wrote:
> It think it would be a real shame not to support non-contiguous data.
> It would be great if such a byte object could be used instead of
> Numeric/numarray arrays when writing extensions. Then I could write C
> extensions that could be made available very easily/efficiently to any
> package supporting it without having to worry about the specific C api
> of those packages. If only contiguous byte objects are supported that
> byte object is not a good option anymore for implementing extensions
> for Numeric unless I am prepared to live with a lot of copying of
> non-contiguous arrays.
I'm hoping I made a good case for a slightly different strategy above. But
even if the metadata did go into the bytes object itself, the metadata
could describe a non-contiguous layout on top of the contiguous chunk of
There is another really valid argument for using the strategy above to
describe metadata instead of wedging it into the bytes object: The Numeric
community could agree on the metadata attributes and start using it
If you wait until someone commits the bytes object into the core, it won't
be generally available until Python version 2.5 at the earliest, and any
libraries that depended on using bytes stored metadata would not work with
older versions of Python.
More information about the Numpy-discussion