Rob Speer writes: >> No. I'd rather go for eliminating the 'arr.year.named', and providing only: >> * arr.__getitem__ >> * arr.named.__getitem__ >> * arr.<label>.__getitem__ >> >> The first being just the current ndarray.__getitem__, and the two last >> methods >> would accept both strings and integers, assuming that names/ticks based on >> integers (e.g., the 1994 above) must be provided as strings, or otherwise are >> treated as good old array indexes.
> There are lots of data types besides strings that make good names > (tuples, for example). I think strings are the most common, but you can still use anything you like as long as it's hashable but not an integer. > My impression from SciPy was that people would prefer separate > accessors for names and indices, especially because integers (a really > common data type, after all) shouldn't be forbidden. Also, working > with strings of integers like '2010' makes me feel like I'm using PHP, > a feeling I like to avoid whenever possible. :) This boils down to one single question: must it be allowed to index with a mix of names (whatever their type) _and_ "good-old" integer indexes that are not "translated"? Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
