Antoine Pitrou <pit...@free.fr> added the comment:
> A further version of the pickle protocol could
> > have a dedicated opcode for sets instead...
>
> -1 We don't have to introduce a new (and backwards incompatible)
> opcode for every possible container type.
What I was implying is that someone interested in more efficient pickles could
start the work of a new protocol version which would *include* such an
improvement.
> All that is saved is the enclosing list or tuple setup (five bytes
> in the case of sets).
No, you would save the (string) reference to "builtins.set" and the whole
constructor invocation boilerplate.
>>> len(pickle.dumps([1,2,3]))
14
>>> len(pickle.dumps({1,2,3}))
36
See? The difference is much more than 5 bytes.
What's more, you would avoid building a temporary list only to convert it to a
set at the end.
> People concerned about pickle size would be much better off investing > time
> into a more generic solution (such as adding a code to
> automatically run zip/gzip/bzip/xz etc).
That's at the expense of (un)pickling speed, though, while the above suggestion
would improve performance in addition to reducing pickle sizes.
----------
_______________________________________
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
