This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author alexandre.vassalotti
Recipients alexandre.vassalotti, pitrou
Date 2013-04-21.06:48:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za>
In-reply-to
Content
I have restarted the work on PEP 3154. Stefan Mihaila had begun an implementation as part of the Google Summer of Code 2012. Unfortunately, he hit multiple roadblocks which prevented him to finish his work by the end of the summer. He previously shown interest in completing his implementation. However he got constrained by time and never resumed his work.

So I am taking over the implementation of the PEP. I have decided to go forward with a brand new code, using Stefan's work only as a guide. At the moment, I have completed about half of the PEP---missing only support for calling __new__ with keyword arguments and the use of new qualified name for referring objects.

Design-wise, there is still a few things that we should discuss. For example, I think Stefan's idea, which is not specified in the PEP, to eliminate PUT opcodes is interesting. His proposal was to emit an implicit PUT opcode after each object pickled and make the Pickler and Unpickler classes agree on the scheme. A drawback of this implicit scheme is we cannot be selective about which object we save in the memo during unpickling. That means, for example, we won't be able to make pickletools.optimize work with protocol 4 to reduce the memory footprint of the unpickling process. This scheme also alters the meaning of all previously defined opcodes because of the implicit PUTs, which is sort of okay because we are changing protocol. Alternatively, we could use an explicit scheme by defining new "fat" opcodes, for the built-in types we care about, which includes memoization. This scheme would a bit more flexible however it would also be slightly more involved implementation-wise. In any case, I will run benchmarks to see if either schemes are worthwhile.
History
Date User Action Args
2013-04-21 06:48:58alexandre.vassalottisetrecipients: + alexandre.vassalotti, pitrou
2013-04-21 06:48:58alexandre.vassalottisetmessageid: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za>
2013-04-21 06:48:58alexandre.vassalottilinkissue17810 messages
2013-04-21 06:48:57alexandre.vassalotticreate