[Numpy-discussion] Response to PEP suggestions
Fernando.Perez at colorado.edu
Thu Feb 17 11:12:21 CST 2005
Just a small comment:
Travis Oliphant wrote:
> Capping indexes was proposed because of what numarray does. I can only
> think that the benefit would be that you don't have to check for and
> raise an error in the middle of an indexing loop or pre-scan the
> indexes. But, I suppose this is unavoidalbe, anyway. Currently Numeric
> allows specifying indexes that are too high in slices. It just chops
> them. Python allows this too, for slices. So, I guess I'm just
> specifying Python behavior. Of course indexing with an integer that is
> too large or too small will raise errors:
> In Python:
> a = [1,2,3,4,5]
> a[:20] works
> a raises an error.
This feature is extremely useful. Just yesterday, I needed some code to check
whether the first character in a (potentially empty) string was one of a
certain list. I couldn't use .startswith(), because I'd have to call it for
each test, and I didn't feel like writing a regexp (since I abandoned Perl
coding, I've mostly forgotten them and I need to look up the syntax every
time). The danger with:
if mystr in ('a','b','c'): ...
is that if mystr is empty, this blows up. Thanks to Python's acceptance of
invalid indices in slices, I used
if mystr[0:1] in ('a','b','c'): ...
This is exactly identical to the first case, except that if the string is
empty, mystr[0:1] returns ''. No need for extra checks, no need for a
try/except block, nothing. Clean, elegant and to the point.
Given that python supports these semantics for all their sliceable containers,
I'd very much vote for numerix doing the same.
There are cases where it makes sense for numerix arrays to have different
semantics from python lists. The slice-as-view is probably the best example.
But unless there is a strong reason to do so, I think numerix arrays should
not deviate from python sequence behavior.
More information about the Numpy-discussion