[Python-Dev] Suggestion: stopping to trust os mtimes

[Tim Peters]

[Moshe]
> How about having, in addition to the time-stamp, the size of the file?
> At least on UNIX, it comes for free with the same stat call.

+1 from me.  Note that, besides inter-machine clock skew, some filesystems
have a timestamp granularity too coarse to distinguish close-in-time writes.
For those (& related) reasons, the attentive Pythoneer will have noted that
all of the winning 1st-round Software Carpentry "make"-replacement designs
provide for alternatives to timestamps.  Tom Tromey's has the clearest
discussion of the problems with timestamps:

http://software-carpentry.codesourcery.com/entries/build/Tromey/Tromey.html

In my industrial experience, (timestamp, size) pairs have never failed in
practice.  However, "my industrial experience" has been entirely in projects
where source-control wrappers add a checkin comment block to every
checked-in file, and that alone made it exceedingly unlikely that any two
successive versions of a file would have the same size.

In Python I'm still (a little) worried about cases like

SOME_GLOBAL_CONFIG_OPTION = 0

where "0" gets replaced by "1" or "2" or ... there are lots of interesting
things you can do to Python programs without changing their size.  At
Dragon, checked-in Python files were also subject to the "checkin comment
block" rule, so no project under source control suffered from this.  I
suspect it burned people in their pre-source-controlled development
projects, though!  One group in particular had a project that involved acres
of machine-generated Python modules, and I know they suffered from coarse
timestamps on their flavor of Unix (so part of their "make" procedure was to
nuke all .pyc's on each build).

it's-easy-to-laugh-at-problems-you-don't-have<wink>-ly y'rs  - tim