> *Apart* from the specific use case of making an exact copy of a > directory tree that can be verified by other tools that simply compare > the nanosecond times for equality, I don't see any reason for > complicating so many APIs to preserve the fake precision. As far as > simply comparing whether one file is newer than another for tools like > make/scons, I bet that it's in practice impossible to read a file and > create another in less than a microsecond. (I actually doubt that you > can do it faster than a millisecond, but for my argument I don't need > that.)
But this leads to the issue with specialized APIs just for nanoseconds (as the one you just proposed): people will use them *just because they are there*. It's like the byte-oriented APIs to do file names: most applications won't need them, either because the file names convert into character strings just fine, or because the emulation that we (now) provide will fall back to some nearly-accurate representation. Still, just because we have the byte APIs, people use them, to then find out that they don't work on Windows, so they will write very complicated code to make their code 100% correct. The same will happen with specialized API for nanosecond time stamps: people will be told to use them because it might matter, and not knowing for sure that it won't matter to them, they will use them. Therefore, I feel that we must not introduced such specialized APIs. Not supporting ns timestamps is something I can readily agree to. However, contributors won't agree to that, and will insist that these be added (and keep writing patches to do so) until it does get added. Some of them are core contributors, so there is no easy way to stop them :-) Regards, Martin _______________________________________________ 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
