Now, the one part I've implemented that I just made up instead of looking to the SciPy consensus (because there was no SciPy consensus) was how to refer to multiple labeled axes without repeating ".axis" all over the place. My choice, which I call "magical axis attributes", is to have arr.somelabel == arr.axis.somelabel whenever it doesn't mean something else. This turns the call arr.axis.country.named['Netherlands'].axis.year[-1] into: arr.country.named['Netherlands'].year[-1]
I got a message from Fernando Perez saying that he didn't like the magical axis attributes, for the expected reason that it's inconsistent. You shouldn't have to refer to your axis differently just because you called it something like "mean". Another problem that just occurred to me is that datarray-using code could break just because DataArray, or even ndarray itself, grew a new method. I like the syntax that magical attributes provide, but I'm willing to consider other options. Here's one: The __getattr__ only does its magic on attribute names that end in "_index" or "_named", which should not conflict with other method names. "arr.foo_index[3]" is the same as "arr.axis.foo[3]". Furthermore, "arr.foo_named['bar']" is the same as "arr.axis.foo.named['bar']". Then the above lookup becomes: arr.country_named['Netherlands'].year_index[-1] I don't find this as appealing as magical attributes, but perhaps it's more responsible. I'd like to know what other people think, so let me summarize and name the existing proposals: arr.axis.country.named['Netherlands'].axis.year[-1] # the default option -- works in any case arr[ arr.aix.country.named['Netherlands'].year[-1] ] # the "stuple" option arr.country.named['Netherlands'].year[-1] # the "magical" option arr.country_named['Netherlands'].year_index[-1] # the "semi-magical" option -- Rob On Fri, Jul 9, 2010 at 1:39 AM, Rob Speer <[email protected]> wrote: > http://github.com/rspeer/datarray represents my best guess at the > SciPy BOF consensus. I recently switched the method of accessing named > ticks from .named() to .named[] based on further discussion here. > > My implementation is still missing the case with named ticks but > positional axes, however. That is, you should be able to use .named > directly on the top-level datarray without referring to any axis > labels, to say something like arr.named['Netherlands', 2010], but you > can't yet. > -- Rob > > On Thu, Jul 8, 2010 at 11:44 PM, Keith Goodman <[email protected]> wrote: >> On Thu, Jul 8, 2010 at 1:20 PM, Fernando Perez <[email protected]> wrote: >> >>> The consensus at the BoF (not that it means it's set in stone, simply >>> that there was good chance for back-and-forth on the topic with many >>> voices) was that: >>> >>> 1. There are valid use cases for 'integer ticks', i.e. integers that >>> index arbitrarily into an array instead of in 0..N-1 fashion. >>> >>> 2. That having plain arr[0] give anything but the first element in arr >>> would be way too confusing in practice, and likely to cause too many >>> problems. >>> >>> 3. That the best solution to allow integer ticks while retaining >>> 'normal' indexing semantics for integers would be to have >>> >>> arr[int] -> normal indexing >>> arr.somethin[int] -> tick-based indexing, where an int can mean anything. >> >> Has the Scipy 2010 BOF consensus been implemented in anyone's fork? I >> don't understand the indexing so I'd like to try it. >> _______________________________________________ >> NumPy-Discussion mailing list >> [email protected] >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
