Currently apptools.persistence.VersionedUnpickler.load is intended to be used with pickle.dump, with pickle imported from the standard library.
The missing dump in apptools to pair with VersionedUnpickler.load limits refactoring and extensions in the future: All customization of the pickling business must happen at the load stage. When VersionedUnpickler.load is used, one (e.g. me) would expect to see a matching dump (e.g. VersionedPickler.dump), and would be worried to see they don't match.
If there is a public API providing dump and load for downstream projects depending on apptools.persistence to use (even though the dump would simply call pickle.dump), more of the library can change, e.g. shifting logic from load to dump, without having to cause backward incompatible breakages downstream. Such an API is also more obvious for developers to use.
Currently
apptools.persistence.VersionedUnpickler.loadis intended to be used withpickle.dump, withpickleimported from the standard library.The missing
dumpinapptoolsto pair withVersionedUnpickler.loadlimits refactoring and extensions in the future: All customization of the pickling business must happen at theloadstage. WhenVersionedUnpickler.loadis used, one (e.g. me) would expect to see a matchingdump(e.g.VersionedPickler.dump), and would be worried to see they don't match.If there is a public API providing
dumpandloadfor downstream projects depending onapptools.persistenceto use (even though thedumpwould simply callpickle.dump), more of the library can change, e.g. shifting logic from load to dump, without having to cause backward incompatible breakages downstream. Such an API is also more obvious for developers to use.