[Tim] >> and filecmp contains a module-level _cache with a funky scheme for >> avoiding file comparisons if various os.stat() values haven't changed. >> But st_mtime on Windows doesn't necessarily change when a file is >> modified -- it has limited resolution (2 seconds on FAT32, and I'm >> having a hard time finding a believable answer for NTFS (which I'm >> using)).
[Martin] > The time stamp itself has a precision of 100ns (it really is a > FILETIME). Right -- see "believable" above ;-) > I don't know whether there is any documentation that > explains how often it is updated; I doubt it has a higher resolution > than the system clock :-) Me too. >> Anyone bored enough to report what happens on Linux? > I had to run it 18 times to get > > test_exceptions > beginning 42 repetitions > 123456789012345678901234567890123456789012 > .......................................... > test_exceptions leaked [203, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0] references > 1 test OK. Thank you! I'm sorry to hear you were so bored ;-) So here's a fun mystery for someone less sleepy than I am at this time: patch 1501987 (which I checked in) appears to have cured this, but neither I nor its author seem to know why. test_exceptions was picking a pickle protocol at random (WTF?!), and the patch makes it try all pickle protocols instead. Now that I typed that, I discovered I really don't care why it cured it, so it's all yours :-) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
