[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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