Fernando Perez writes:
> 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.
Thanks for the summary. Then, does it make sense this scheme?
arr[int] -> normal indexing
arr[not int] -> IndexError
arr.something[int] -> normal indexing (use str(int) for tick-based indexing)
arr.something[not int] -> tick-based indexing
It's not that I'm trying to push for this scheme. In fact, my question is
whether this would be of any practical use. (e.g., arr.something['1900':-3], or
arr.named[0,'1900':])
If that is acceptable and performance wouldn't have a huge drop, then I'd rather
go for:
arr[int] -> normal indexing
arr[not int] -> tick-based indexing
I'm not sure if this was dropped because of the str(int) or
because of performance reasons
arr.something[int] -> normal indexing
arr.something[not int] -> tick-based indexing
arr.named -> no longer necessary
Which has even less "keywords" to remember.
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
