On 2/2/2012 6:28 AM, Antoine Pitrou wrote:
On Thu, 2 Feb 2012 15:09:41 +0100
Victor Stinner<victor.stin...@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.
_______________________________________________
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
