Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
> 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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9120>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
