== Some things to remember when implementing ((__getitem__)) I've recently been doing some work on classes derived from _list_ and _tuple_ that fiddle with the behavior of ((__getitem__)), and ran into a couple of surprises that I am going to write down so that I remember them in the future: * for the simple '_obj[i:j]_' case, ((__getitem__)) is not called if the class has a ((__getslice__)) method. _list_ and _tuple_ both do, despite the method being labeled as deprecated since Python 2.0. * the moment you use an _i_ or _j_ that is not a simple integer (including floating point numbers, but not including long integers), it turns into a call to ((__getitem__)) with a slice object as the key. (This is [[simple slicing http://docs.python.org/ref/slicings.html]].) Supporting the [[full slice syntax http://docs.python.org/ref/slicings.html]] in a ((__getitem__)) implementation makes my head hurt; you can get handed a slice object, or a tuple that can contain at least slice objects, ellipsis objects, and numbers (and probably more that I don't know about). Just throw TypeError instead; it's what lists and tuples do. Checking that your ((__getitem__)) has not been called with such things, so that you can throw TypeError appropriately, is harder than it should be. I personally wish that ((__getitem__)) wasn't so generic; it seems un-Pythonic to have to inspect the type of your argument to figure out what to do with it. (The better way would be to have one method to implement plain subscripting, one for simple slices, and a third one for extended slicing. Unfortunately it's too late for that now.)