[Python-ideas] Add a cryptographic hash (e.g SHA1) of source toPython Compiled objects?

rocky at gnu.org rocky at gnu.org
Sat Feb 7 02:14:37 CET 2009

Clearly I've failed to make any compelling cases. So be it. Thanks for

Brett Cannon writes:
 > On Fri, Feb 6, 2009 at 12:10,  <rocky at gnu.org> wrote:
 > >  > I still don't see the benefit of knowing what version of Python a
 > >  > magic number matches to. So I know some bytecode was compiled by
 > >  > Python 2.5 while I am running Python 2.6.
 > >
 > > Yep. Not uncommon for me to have several versions of Python
 > > available. It so happens that the computer where this email is being
 > > sent has at least 9 versions, possibly more because I didn't check if
 > > python.new and python.old are one those other 9. (I don't maintain
 > > this box, but pay someone else to; clearly this is a pathological
 > > case, but it's kind of interesting to me that there are at more than 9
 > > versions installed and I did not contrive this case.)
 > >
 > >
 > >  > What benefit do I derive
 > >  > from knowing that compared to just knowing that it was not compiled by
 > >  > Python 2.6? I mean are you ultimately planning on launching a
 > >  > different interpreter based on what generated the bytecode?
 > >
 > > If there's a mismatch in the first place, it means there's confusion
 > > on someone's part. Don't you want to foster development of programs
 > > that try to minimize confusion?
 > Come on, that is such a baiting question. You view adding a dict of
 > the versions as a way to help deal with confusion in a case where
 > someone actually cares about which version of bytecode is used. I view
 > it as another API someone is going to have to maintain for a use case
 > I do not see as justifying that maintenance. Bytecode is purely a
 > performance benefit, nothing more. This is why we so readily
 > reconstruct it. Heck, in Python 3.0 the __file__ attribute *always*
 > points to the .py file even if the .pyc was used for the load.
 > > Subsidiary effects when support of
 > > magic to version string are not readily available in situations where
 > > it would be helpful is possibly back and forth dialog in bug reports
 > > one is asking what telling folks how to get the version number
 > > (because it's not in the error message because its not readily
 > > available by a programmer).
 > I have never had a bug report come in where I had to care about he
 > magic number of a .pyc file.
 > > Never underestimate the level of users,
 > > especially if you are working on something like a debugger.
 > >
 > I don't, else I would not be a Python developer. But along with not
 > underestimating also means that if you need to worry about something
 > like what version of Python generates what magic number then you can
 > look at Python/compile.c just as easily without me adding some code
 > that has to be maintained.
 > > If we hope that someone's going to know about and read that comment in
 > > the C file turn it into a dictionary and maintain it anytime the magic
 > > number gets updated, it's probably not going to happen often.
 > >
 > Nope, it probably won't, and honestly I am fine with that.
 > > Again, although I see specific uses in a debugger this really an issue
 > > regarding code tools or programs that deal with Python code. I know
 > > there's a disassembler, but you mean there isn't a dump tool which
 > > shows all of the information inside a compiled object including a
 > > disassembly, Python version the program was compiled with, mtime in
 > > human readable format, and whatnot?
 > >
 > Just so there is no confusion: a .pyc is not a compiled object, but a
 > file containing a magic number, mtime, and a marshaled code object.
 > And no, there is nothing in the standard library that dumps all of
 > this data out for a .pyc. This is somewhat on purpose as we make no
 > hard guarantees we won't change the format of .pyc files at some point
 > (see the python-ideas list for a discussion about changing the format
 > to allowing a variable amount of metadata).
 > -Brett

More information about the Python-ideas mailing list