New submission from Antoine Pitrou pit...@free.fr:
test_import fails when run directly after test_coding:
$ ./python -m test test_coding test_import
[1/2] test_coding
[2/2] test_import
test test_import failed -- Traceback (most recent call last):
File
Antoine Pitrou pit...@free.fr added the comment:
The cause is that the import machinery checks the timestamp stored in the pyc
file to decide whether it must be refreshed. Depending on the system's
timestamp granularity, there can be false negatives: the py file was modified
twice with the
Antoine Pitrou pit...@free.fr added the comment:
The pyc format currently stores the modification time cast to a 32-bit int. A
3.3 iteration of the pyc format could instead store two 32-bit ints, one for
the integral part and one for the fractional part (e.g. in nanoseconds). When
Charles-François Natali neolo...@free.fr added the comment:
a struct timespec providing theoretical nanosecond precision.
Indeed. EXT3's timestamps have a 1s granularity, for example.
Another possibility would be to store both mtime and st_size (it's the default
heuristic used by rsync does
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset f4afc6858ed2 by Antoine Pitrou in branch '3.2':
Issue #13645: fix test_import failure when run immediately after test_coding.
http://hg.python.org/cpython/rev/f4afc6858ed2
New changeset a6bd166abde5 by Antoine
Antoine Pitrou pit...@free.fr added the comment:
In the meantime, I've committed the test patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13645
___
Antoine Pitrou pit...@free.fr added the comment:
Indeed. EXT3's timestamps have a 1s granularity, for example.
Another possibility would be to store both mtime and st_size (it's the
default heuristic used by rsync does to decide whether to skip a
file).
Good idea. It would also avoid too
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13645
___
___
Python-bugs-list
