[Python-Dev] Should there be a source-code checksum in module objects?

rocky at gnu.org rocky at gnu.org
Mon Feb 2 19:48:44 CET 2009


Brett Cannon writes:
 > On Mon, Feb 2, 2009 at 00:52, Rocky Bernstein <rocky at gnu.org> wrote:
 > > As I've mentioned, I've been re-examining from ground up the whole
 > > state of affairs in writing a debugger.
 > >
 > > One of the challenges of a debugger or any source-code analysis tool
 > > is verifying that the source-code that the tool is reporting on
 > > corresponds to the compiled object under execution. (For debuggers,
 > > this problem becomes more likely to occur when you are debugging on a
 > > computer that isn't the same as the computer where the code is
 > > running.)
 > >
 > > Is there a checksum of the source text computed and stored in
 > > compilation?
 > 
 > No, only the bytecode version used, the mtime of the source the
 > bytecode is derived from, and the bytecode itself.
 > 
 > > If not, should there be one?
 > 
 > If you are planning to read this directly from the .pyc file then it
 > is not needed as the mtime timestamp in the .pyc should in general be
 > enough to detect changes to the source.

I'm not sure I understand. I am debugging program P on computer A
which may have (probably did?) do a compile. I am on computer B which
I have the source code. Maybe it is checked out from a version control
system same as on A. Maybe it has bytecodes, maybe not. But the
expectation is that the programmer thinks it matches what is currently
on A that the programmer is debuggging. Can I tell for certain?

Suppose I'm writing a code coverage tool which can accumulate
statistics over many runs. I notice that the date on the Python file
changes, again one way it might is that it might be checked out fresh
and subversion for example will put in a current timestamp. How can
the code coverage tool know that the source hasn't changed even though
the file may have disappeared or maybe was modified several times but
in the end stays the same?

Thanks.

 > 
 > -Brett
 > 


More information about the Python-Dev mailing list