> We don't have to introduce a new (and backwards incompatible)
> opcode for every possible container type.

I would draw the line at containers that have literal syntax (and necessarily have dedicated .pyc opcode).

This begs a question, however: why not use regular python bytecode in pickles?

I understand that originally pickle bytecode was supposed to restrict what functionality is available to unpickler, but this is a moot point these days.

The pickle documentation has a big red security warning (and some want to make it even bigger and redder, issue9105.)

Indeed, I've just checked that the following works:

>>> from pickle import *
>>> class evil:
...    def __reduce__(self):
...        return (exec, ("print('pwned!')",)) 
... 
>>> s = dumps(evil())
>>> loads(s)
pwned!


The advantages of using standard bytecode are numerous:

1. Python bytecode is much better understood than pickle bytecode.  Since it is exercised by every python program, bugs related to bytecode execution tend to be found and fixed quickly while pickle bytecode is considered to be quirky by many.

2. Much more effort had been spend on optimizing various aspects of python bytecode than pickle bytecode.

3. Using python bytecode will remove numerous arbitrary restrictions that current pickle protocol has such as not being able to pickle non module-level objects or anonymous functions.

The only downside I can think of is that doing this would place an extra constraint on bytecode evolution because pickles written by current version of python should remain loadable in all future versions.