[issue5128] compileall: consider ctime

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue5128] compileall: consider ctime

Brett Cannon added the comment: There is no patch, Djoume, but honestly that's fine since if you want to submit a change to something it should go in a new issue. But honestly compileall needs to be rewritten in Python 3.4 to use importlib and have it control when source code should be rebuilt

[issue5128] compileall: consider ctime

Djoume Salvetti added the comment: This patch introduces a slight change in behaviour. Now compilation will only happen if there is a difference in the number of seconds in the timestamp of files, before this patch any difference in mtime will trigger a rebuild. This is because the timestamp i

[issue5128] compileall: consider ctime

Brett Cannon added the comment: Committed in 69481 and 69482 for trunk and py3k, respectively. Had to rewrite the test code but the compileall patch went in fine. Thanks, Martin! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _

[issue5128] compileall: consider ctime

Changes by Ingmar Vanhassel : -- nosy: +ingmar ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue5128] compileall: consider ctime

Brett Cannon added the comment: On Sun, Feb 8, 2009 at 09:15, Martin von Gagern wrote: > > Martin von Gagern added the comment: > > Any progress with the review? > I am planning to get to it on Tuesday. > By the way, what branch are we aiming for? 2.7/3.1. It's a backwards-incompatible chan

[issue5128] compileall: consider ctime

Martin von Gagern added the comment: Any progress with the review? By the way, what branch are we aiming for? I'm using 2.5 here, so I reported this issue against that version, and wrote the patch against that branch. I guess it should work for trunk as well, but the imports of with_statement f

[issue5128] compileall: consider ctime

Martin von Gagern added the comment: Not being a regular Python programmer myself, I've never even heard of a context manager before, but this latest patch should fit the bill. As for tests, I believe that a few two-second sleeps (as FAT has only two second resolution iirc) should avoid the kin

[issue5128] compileall: consider ctime

Brett Cannon added the comment: Patch is really close. Can you use a context manager for the file management? That way the file is guaranteed to be closed without issue. ___ Python tracker __

[issue5128] compileall: consider ctime

Brett Cannon added the comment: On Mon, Feb 2, 2009 at 13:50, Brett Cannon wrote: > On Mon, Feb 2, 2009 at 12:42, Martin von Gagern > wrote: >> >> Martin von Gagern added the comment: >> >> Next iteration. With magic number, and now also closing the file again. >> I changed from unpack and n

[issue5128] compileall: consider ctime

Brett Cannon added the comment: On Mon, Feb 2, 2009 at 12:42, Martin von Gagern wrote: > > Martin von Gagern added the comment: > > Next iteration. With magic number, and now also closing the file again. > I changed from unpack and number comparison to pack and string > comparison, makes thing

[issue5128] compileall: consider ctime

Martin von Gagern added the comment: Next iteration. With magic number, and now also closing the file again. I changed from unpack and number comparison to pack and string comparison, makes things a bit easier, as there is only one comparison, and as underflow of the packed data isn't an issue a

[issue5128] compileall: consider ctime

Brett Cannon added the comment: If you want an easy way to see how bytecode is checked, look at importlib._bootstrap in Python 3.1: http://svn.python.org/view/python/branches/py3k/Lib/importlib/_bootstrap.py?view=markup . Specifically, look at the get_code() method for _PyFileLoader. __

[issue5128] compileall: consider ctime

Changes by Brett Cannon : -- assignee: -> brett.cannon stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue5128] compileall: consider ctime

Brett Cannon added the comment: On Mon, Feb 2, 2009 at 12:22, Martin von Gagern wrote: > > Martin von Gagern added the comment: > > Like this? Don't have the time right now to do a code review right now, but hopefully I can get to this soon. > Should the magic number be checked as well, If

[issue5128] compileall: consider ctime

Martin von Gagern added the comment: Like this? Should the magic number be checked as well, and if so, against what value? I couldn't find that constant in any structure accessible from python, and jumping through hoops seems too much, as updating the python version should probably result in all

[issue5128] compileall: consider ctime

Brett Cannon added the comment: The problem is not that ctime should be taken into account, but that the .pyc file should be read for its timestamp and that should be used. Otherwise you are still deviating from what Python uses internally to decide whether bytecode should be regenerated. -

[issue5128] compileall: consider ctime

Changes by Martin von Gagern : -- keywords: +patch Added file: http://bugs.python.org/file12917/compileall-ctime.patch ___ Python tracker ___ _

[issue5128] compileall: consider ctime

New submission from Martin von Gagern : When trying to decide whether or not a given file needs to be recompiled, the inode creation time should be taken into account along with the file modification time. Scenario: Suppose you have three times, A < B < C < D. At time A, you package version 1 of