IMO if we want to use the index machinery -- which seems like a fine idea
-- then it should go like: this code uses is-this-an-integer scalar
machinery; the is-this-an-integer machinery uses the index machinery
(possibly among other things). Agree on the boolean stuff but that's a
separate issue...

On Wed, Jan 2, 2013 at 3:00 PM, seberg <notifications@github.com> wrote:

> In numpy/fft/helper.py:
>
> > @@ -58,7 +59,7 @@ def fftshift(x, axes=None):
> >      ndim = len(tmp.shape)
> >      if axes is None:
> >          axes = range(ndim)
> > -    elif isinstance(axes, (int, nt.integer)):
> > +    elif isinstance(axes, _integer_types):
>
> With 2.4 support dropped I was going to suggest generally using the index
> machinery (maybe through try: axes = operator.index(axes) except
> TypeError: ... for such cases. This lets python bools slip past. It lets
> numpy scalar bools slip past too, but not python 0-d arrays. On first sight
> it seems to me like exactly what __index__ should be good for, but I am
> not really certain that it is perfectly right.
> To be honest I find the python behaviour with bools irritating because
> np.arange(10)[np.array(True)] would be (if it worked) most logically be
> np.arange(10), but by python logic (also right now) np.arange(10)[True]
> == 1. (Same difference exists for 0-d arrays, already works but is an
> open issue)
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/numpy/numpy/pull/2876/files#r2528893>.
>
>