(original) (raw)
On 2/2/2012 6:28 AM, Antoine Pitrou wrote:On Thu, 2 Feb 2012 15:09:41 +0100 Victor Stinner <victor.stinner@haypocalc.com> wrote:
Why int? That doesn't seem to bring anything.
It helps to deprecate/replace os.stat_float_times(), which may be used
for backward compatibility (with Python 2.2 ? :-)).
I must admit I don't understand the stat_float_times documentation:“For compatibility with older Python versions, accessing stat_result as
a tuple always returns integers.Python now returns float values by default. Applications which do not
work correctly with floating point time stamps can use this function to
restore the old behaviour.”These two paragraphs seem to contradict themselves.
That said, I don't understand why we couldn't simply deprecate
stat_float_times() right now. Having an option for integer timestamps
is pointless, you can just call int() on the result if you want.Regards
Antoine.
Sorry to bring this up, but the PEP should probably consider another
option: Introducing a precedent following os.stat_decimal_times().
Like os.stat_float_times, it would decide the return types of
timestamps from os.stat. Or something along that line. Having it
affect the results of time.time would be weird, though. And the
whole design of os.stat_float_times smells of something being
designed wrong in the first place, to need such an API to retain
backward compatibility. But I'm not sure it is, even yet, designed
for such flexibility.