[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review (original) (raw)

Guido van Rossum guido at python.org
Wed Feb 15 22:32:51 CET 2012

On Wed, Feb 15, 2012 at 11:38 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:

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.

You have a point, but applies just as much to the proposal in the PEP -- floats and Decimal are often not quite compatible, but people will pass type=Decimal to the clock and stat functions just because they can. The problems with mixing floats and Decimal are probably just as nasty as those with mixing byte and str. At least if people are mixing nanoseconds (integers) and seconds (floats) they will quickly notice results that are a billion times off.

Not supporting ns timestamps is something I can readily agree to.

Me too.

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 :-)

Actually I think a rejected PEP would be an excellent way to stop this.

Maybe an alternative PEP could be written that supports the filesystem copying use case only, using some specialized ns APIs? I really think that all you need is st_{a,c,m}time_ns fields and os.utime_ns().

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list