[Python-Dev] Fix import errors to have data
tim.peters at gmail.com
Mon Aug 2 01:11:55 CEST 2004
> I understand the point there for reload(), but don't know of other use
> cases (let alone common ones <wink>) for wanting to leave a module in
> sys.modules when its code fails. What are they? Maybe it would be
> better for PyImport_ExecCodeModuleEx to purge a broken module
> unconditionally, and change PyImport_ReloadModule to put it back?
Attached is a patch that takes that approach. Code feels
simpler/cleaner, since it makes a special case out of reload() instead
of a special case out of everything except reload(). Still haven't
thought of a case other than reload() that wants special treatment.
The whole test suite still passes; it still fixes all the spurious
test failures I know about on Windows when running the suite with -r.
The internal _RemoveModule() is incidentally more careful in this
version of the patch. The last patch's new _AddModuleEx() no longer
-------------- next part --------------
RCS file: /cvs-repository/ZODB3/Tools/Attic/fsrefs.py,v
retrieving revision 18.104.22.168
diff -c -u -r22.214.171.124 fsrefs.py
--- fsrefs.py 10 Jul 2004 02:42:11 -0000 126.96.36.199
+++ fsrefs.py 11 Jul 2004 01:45:23 -0000
@@ -20,12 +20,13 @@
fsrefs.py checks object sanity by trying to load the current revision of
every object O in the database, and also verifies that every object
-directly reachable from each such O exists in the database. Note that
-application code implementing objects (or at least defining their classes)
-must be available, an d on PYTHONPATH, for fsrefs to work, because objects
-are actually loaded. On a ZEO server, all the application code typically
-isn't present, so it may be difficult to run fsrefs usefully on a ZEO
+directly reachable from each such O exists in the database.
+It's hard to explain exactly what it does because it relies on undocumented
+features in Python's cPickle module: many of the crucial steps of loading
+an object are taken, but application objects aren't actually created. This
+saves a lot of time, and allows fsrefs to be run even if the code
+implementing the object classes isn't available.
A read-only connection to the specified FileStorage is made, but it is not
recommended to run fsrefs against a live FileStorage. Because a live
@@ -36,10 +37,7 @@
fsrefs doesn't normally produce any output. If an object fails to load, the
oid of the object is given in a message saying so, and if -v was specified
then the traceback corresponding to the load failure is also displayed
-(this is the only effect of the -v flag, and is usually very helpful; -v is
-recommended for normal use). Note that, as mentioned above, a common
-problem is to get a "failed to load" message simply because the module
-containing the class of the object isn't on PYTHONPATH.
+(this is the only effect of the -v flag).
Two other kinds of errors are also detected, one strongly related to
"failed to load", when an object O loads OK, and directly refers to a
@@ -56,6 +54,10 @@
seen by fsrefs before P, an "O refers to the unloadable P" message will
not be produced; a message saying that P can't be loaded will be
produced when fsrefs later tries to load P, though.
+fsrefs also (indirectly) checks that the .index file is sane, because
+fsrefs uses the index to get its idea of what constitutes "all the objects
+in the database".
Note these limitations: because fsrefs only looks at the current revision
of objects, it does not attempt to load objects in versions, or non-current
More information about the Python-Dev