Gregory P. Smith added the comment: We already use zipimport for most production deployments. It works well. We've modified our own zipimport to ignore timestamps as keeping them in sync between pyc and py files in the zip files own timestamps is painful. Unfortunately the stdlib zipimport actually checks pyc timestamps against py files in the .zip file in 3.4 and 2.7 (https://hg.python.org/cpython/file/e8878579eb68/Modules/zipimport.c#l1187 mtime is checked, despite a comment in there in 3.4 suggesting it is probably pointless). Changing that is a separate issue (I'll go open one).
Where this hurts us the most is in our build system when not building a final production zipped up binary (which would take as long as loading all of the py and pyc files would and would prevent iterative development). Our py files and pyc files are located on a read only build artifact object store. As a mounted filesystem it does not have a POSIX concept of file mtime at all (and never will). When you're using a readonly filesystem of build time generated .py code without the concept of an mtime you really really want to tell Python to trust the build system and assume pyc files it finds match the corresponding py files. Or your large application/test start up time really suffers. In our use case, it is on the order of a 30% startup time improvement to use precompiled pyc files for our generated code py files (a ton of protobuf python modules) on a large application. Most people are likely not in this situation because they are just lowly individuals operating on a simple writable posix filesystem in front of them. But when it matters, it really matters. People should be able to tell Python "trust me, i know what I'm doing" when it comes to compiled code loading. It is easy enough to modify compile to write a "never verify this" magic timestamp into a pyc. (I'd get more creative and use a value other than all 0s or 1s; pick the release date of the first version Python as your magic timestamp for example; nothing is likely to accidentally end up with that date in it) That's all this issue is asking for. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23723> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
