The first test isn't surprising; three elements are removed off the end.

The second test is a bit surprising. Only two elements are removed. Why?

List iteration in Python essentially consists of an incrementing index into the list. When you delete an element you shift all the elements on the right over. This may cause the index to point to a different element.

Illustratively:

start of loop
[0,0,0,1,2,3,4,5,6]
 ^   <-- position of index

delete first element (since current element = 0)
[0,0,1,2,3,4,5,6]
 ^

next iteration
[0,0,1,2,3,4,5,6]
   ^

delete first element (since current element = 0)
[0,1,2,3,4,5,6]
   ^

and from now on no zeros are encountered, so no more elements are deleted.

---

To avoid confusion in the future, try not to modify lists while you're iterating over them. While Python won't complain (unlike dictionaries, which cannot be modified during iteration), it will result in weird and usually counterintuitive situations like this one.

Nice observation! You are correct in that the performance of pop(0) is significantly slower than pop() for large lists (above 10,000 elements). See timeit results below. I believe @Kenneth Love (https://teamtreehouse.com/kennethlove) chose to pop from the front of the list as a straight-forward logical approach without trying to optimize for performance. Since the order of monsters in the list is arbitrary, popping from the back or the front isn't a requirement and either approach would work functionally. Using timeit in the python REPL: ```python import timeit stmt1 = "while foo: it = foo.pop();" stmt2 = "while foo: it = foo.pop(0);" Run on 1000 element list setup = "foo = list(range(1000))" timeit.timeit(stmt1, setup) 0.051728010177612305 timeit.timeit(stmt2, setup) 0.05761384963989258 Run on 10,000 element list setup = "foo = list(range(10000))" timeit.timeit(stmt1, setup) 0.05236983299255371 timeit.timeit(stmt2, setup) 0.06780695915222168 Run on 100,000 element list setup = "foo = list(range(100000))" timeit.timeit(stmt1, setup) 0.0552210807800293 timeit.timeit(stmt2, setup) 1.3619050979614258 Run on 1,000,000 element list setup = "foo = list(range(1000000))" timeit.timeit(stmt1, setup) 0.10635495185852051 timeit.timeit(stmt2, setup) 226.78901600837708 ```

You shouldn't modify the list while iterating over it. It leads to weirdness like this.

I don't know anything about C but want to share my insight and it'd be too long for a comment.

That's the pop implementation.

If pop arg is the last element in the list, it calls list_resize which doesn't seem to be too complicated.

    if (index == Py_SIZE(self) - 1) {
        status = list_resize(self, Py_SIZE(self) - 1);
        if (status >= 0)
            return v; /* and v now owns the reference the list had */
        else
            return NULL;

Otherwise list_ass_slice is called. It happens it has a comment in it

/* Because [X]DECREF can recursively invoke list operations on this list, we must postpone all [X]DECREF activity until after the list is back in its canonical shape. Therefore we must allocate an additional array, 'recycle', into which we temporarily copy the items that are deleted from the list. :-( */

I'd assume that's where the performance is lost, on this temporary allocation.

I'm assuming, based on your phrasing, that self.items is a list. The pop method for lists, as you've pointed out, can be used to remove and return an element of the list at a specified index. If you omit the index, then the last item is removed and returned.

Either way, pop returns the item that was removed. If you put [0] after the call to pop, you'll get the first item of the item that was popped. So, if self.items is [[1, 2, 3], [4, 5, 6]], then self.items.pop() would be [4, 5, 6] and therefore self.items.pop()[0] would be 4.