In pickle.py, load_appends is currently defined as

    def load_appends(self):
        stack = self.stack
        mark = self.marker()
        list = stack[mark - 1]
        list.extend(stack[mark + 1:])
        del stack[mark:]

However, according to the spec of APPENDS, it should actually be:

    def load_appends(self):
        obj = stack[mark - 1]
        items = stack[mark + 1:]
        if isinstance(obj, list):
            obj.extend(items)
        else:
            for item in items:
                obj.append(item)

This will match with the current behaviour of _pickle.

Your patch is bogus (duplicated load_appends definition).
Also, I think you want to add a test if you want to avoid further regressions.

Yes, test is needed. Current tests don't cover this case.

I suggest to move obj.append out of the tight loop, as in C implementation.

            append = obj.append
            for item in items:
                append(item)

Alright alright! Here's a less bogus patch. :)

New changeset 37139694aed0 by Alexandre Vassalotti in branch '3.3':
Isuse #17720: Fix APPENDS handling in the Python implementation of Unpickler
http://hg.python.org/cpython/rev/37139694aed0

Why this patch was not applied to 2.7? What is the spec of APPENDS?

From PEP 7:

    listitems    Optional, and new in this PEP.
                 If this is not None, it should be an iterator (not a
                 sequence!) yielding successive list items.  These list
                 items will be pickled, and appended to the object using
                 either obj.append(item) or obj.extend(list_of_items).
                 This is primarily used for list subclasses, but may
                 be used by other classes as long as they have append()
                 and extend() methods with the appropriate signature.
                 (Whether append() or extend() is used depends on which
                 pickle protocol version is used as well as the number
                 of items to append, so both must be supported.)

Both append() or extend() must be supported, therefore old code was correct. C implementation can be optimized by using extend().

I don't recall where I picked up the referred spec. Looking at PEP 307 and pickle docs [1], it does look like that objects which provides the listitems field of the reduce tuple should support extend() too.

It might best to try both in the implementation to avoid breaking existing code that relies on the previous behavior.

[1]: https://docs.python.org/3/library/pickle.html#object.__reduce__

Thanks. Opened issue29368 for this.

> From PEP 7:

Sorry, I meant PEP 307 of course.