]> granicus.if.org Git - python/commitdiff
Paul Rubin reminds me that of course a class's constructor /could/ get
authorBarry Warsaw <barry@python.org>
Sun, 18 Nov 2001 16:24:01 +0000 (16:24 +0000)
committerBarry Warsaw <barry@python.org>
Sun, 18 Nov 2001 16:24:01 +0000 (16:24 +0000)
called, if the pickler found a __getinitargs__() method.

Doc/lib/libpickle.tex

index d6f1c2ebbd62ce6c269868b19a998c00047b4d4d..6018497f3e7f24aa4d91f75c01f539239e56fe58 100644 (file)
@@ -604,10 +604,12 @@ evil things like call \code{os.unlink()} with an arbitrary file name.
 See section~\ref{pickle-protocol} for more details.
 
 For safely unpickling class instances, you need to control exactly
-which classes will get created.  The issue here is usually not that a
-class's constructor will get called --- it won't by the unpickler ---
-but that the class's destructor (i.e. its \method{__del__()} method)
-might get called when the object is garbage collected.  The way to
+which classes will get created.  Be aware that a class's constructor
+could be called (if the pickler found a \method{__getinitargs__()}
+method) and the the class's destructor (i.e. its \method{__del__()} method)
+might get called when the object is garbage collected.  Depending on
+the class, it isn't very heard to trick either method into doing bad
+things, such as removing a file.  The way to
 control the classes that are safe to instantiate differs in
 \module{pickle} and \module{cPickle}\footnote{A word of caution: the
 mechanisms described here use internal attributes and methods, which