You have three questions:
__xx__ method has numpy overridden/defined to handle fancy indexing?
The indexing operator
 is overridable using
__delitem__. It can be fun to write a simple subclass that offers some introspection:
>>> class VerboseList(list): ... def __getitem__(self, key): ... print(key) ... return super().__getitem__(key) ...
Let’s make an empty one first:
>>> l = VerboseList()
Now fill it with some values. Note that we haven’t overridden
__setitem__ so nothing interesting happens yet:
>>> l[:] = range(10)
Now let’s get an item. At index
0 will be
>>> l 0 0
If we try to use a tuple, we get an error, but we get to see the tuple first!
>>> l[0, 4] (0, 4) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 4, in __getitem__ TypeError: list indices must be integers or slices, not tuple
We can also find out how python represents slices internally:
>>> l[1:3] slice(1, 3, None) [1, 2]
There are lots more fun things you can do with this object — give it a try!
2. Why don’t python lists natively support fancy indexing?
This is hard to answer. One way of thinking about it is historical: because the
numpy developers thought of it first.
You youngsters. When I was a kid…
Upon its first public release in 1991, Python had no
numpy library, and to make a multi-dimensional list, you had to nest list structures. I assume that the early developers — in particular, Guido van Rossum (GvR) — felt that keeping things simple was best, initially. Slice indexing was already pretty powerful.
However, not too long after, interest grew in using Python as a scientific computing language. Between 1995 and 1997, a number of developers collaborated on a library called
numeric, an early predecessor of
numpy. Though he wasn’t a major contributor to
numpy, GvR coordinated with the
numeric developers, extending Python’s slice syntax in ways that made multidimensional array indexing easier. Later, an alternative to
numeric arose called
numarray; and in 2006,
numpy was created, incorporating the best features of both.
These libraries were powerful, but they required heavy c extensions and so on. Working them into the base Python distribution would have made it bulky. And although GvR did enhance slice syntax a bit, adding fancy indexing to ordinary lists would have changed their API dramatically — and somewhat redundantly. Given that fancy indexing could be had with an outside library already, the benefit wasn’t worth the cost.
Parts of this narrative are speculative, in all honesty.1 I don’t know the developers really! But it’s the same decision I would have made. In fact…
It really should be that way.
Although fancy indexing is very powerful, I’m glad it’s not part of vanilla Python even today, because it means that you don’t have to think very hard when working with ordinary lists. For many tasks you don’t need it, and the cognitive load it imposes is significant.
Keep in mind that I’m talking about the load imposed on readers and maintainers. You may be a whiz-bang genius who can do 5-d tensor products in your head, but other people have to read your code. Keeping fancy indexing in
numpy means people don’t use it unless they honestly need it, which makes code more readable and maintainable in general.
3. Why is numpy’s fancy indexing so slow on python2? Is it because I don’t have native BLAS support for numpy in this version?
Possibly. It’s definitely environment-dependent; I don’t see the same difference on my machine.
1. The parts of the narrative that aren’t as speculative are drawn from a brief history told in a special issue of Computing in Science and Engineering (2011 vol. 13).