On Wed, Jul 21, 2010 at 10:41 AM, Bruce Southey <bsout...@gmail.com> wrote:
> The current implemented option of allowing strings is the only practical > option and I think that most other related languages also impose this > constraint. Otherwise we will effectively break compatibility with Python > and numpy because darr[0] can result in different answers depending on the > type of object involved - especially if you are using views and forget the > actual object type. There are axis labels (currently string only) and there are tick labels (currently anything but int). darr[0] will always return the first element of the datarray. No indexing by tick label is allowed. To index by tick label you'd have to use a special method like darr.lix[...]. Would that be OK? > I do think that we do have to avoid adding complexity that increases runtime > like looking for the label 2 when it should be the second axis. Also we have > to avoid situations that lead to input errors like flag values or extra > arguments. It's nice to make thing general by allowing any hashable object to label an axis. But I agree with you that we have to watch the cost of doing so. Nothing was decided as final at the metting. We only discussed options. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion