Magnus Lie Hetland writes:
> Tim Churches <tc...@op...>:
> [snip]
> > Just like this:
> >
> > >>> import Numeric
> > >>> a = Numeric.array(['a','b','c'],typecode=Numeric.PyObject)
> > >>> a
> > array([a , b , c ],'O')
> > >>>
>
> As you may have noticed from my previous descriptions, I'm using
> numarray, not Numeric. I've used this in Numeric before -- I just
> can't find the equivalent functionality in numarray :)
>
At the moment, PyObject arrays are not supported (mainly because
it hasn't been a priority for our needs yet. But if all one needs
is such an array to hold PyObjects and nothing more (for example,
we envisioned more sophisticated uses such as apply object methods
to the array and returning arrays of the results) than associative
purposes (and being able to set and get array values), it should
be quite easy to add this capability. In fact one could subclass
NDArray and just define the _get and _setitem methods (I forget
the exact names) and probably customize the __init__ and have
the functionality that you need. I can take a look at it next
week (or if you feel bold, look at NDArray yourself). As with
Numeric, speed is sacrificed when using such arrays. The presumption
is that one is using Numeric or numarray on such things mainly for
the convenience of the array manipulations, not the kind of
efficiency that bulk numerical operations provide.
Combining that with RecordArrays may be a bit trickier in the
sense that RecordArrays presume that records use the same buffer
for all data. If one doesn't mind storing PyObject pointers in
that data array, it probably is also fairly simple to extend
it (but I frankly haven't thought this through so I may be wrong
about how easy it is). Doing this may require some thought about
how to pickle such arrays. Of course, one may have a set of arrays
as Tim suggests which also acts like a record array where there is
no single data buffer. Our RecordArrays were intended to map
to data files closely, but other variants are certainly possible.
Perry Greenfield
|
