[Python-Dev] float atime/mtime/ctime - a bad idea?

[Martin v. Loewis]

Guido van Rossum <guido@python.org> writes:

> I just found a place in my own code that broke because stat now
> returns floats for mtime etc.  I was using a Zope "OIBTree" object,
> which is a dict-like extension type mapping strings to ints; it
> very reasonbly doesn't like it if you assign a float to it.

In this case, could you fix your code by truncating/rounding, or by
using a different container?

> Maybe we can introduce a variant of the stat() function that returns
> floats, or alternative field names that are only available when using
> attributes (not when using the tuple-ish API)?

Assuming that in all cases of breakage it would be possible to easily
"fix" the code somehow, I'd like to have a migration plan, following
PEP 5: I.e. together with adding a new feature for float time stamps,
we should deprecate the old feature (of int time stamps) - perhaps not
right now, but as a pending deprecation. Then, after some time, we
should drop the old feature and continue with just the new one.

So I'd like to see a solution which does not look ugly when the
deprecated feature is gone and just the new feature stays.

Perhaps a flag "times_are_float" would be the right approach?
N: flag defaults to False, users need to ask for floats explicitly
N+1: omitting the flag is deprecated
N+2: flag defaults to True, users need to ask for ints explicitly
N+5: the flag is removed

There are variations to this plan, adding a phase where it is an error
to omit the flag, or where a pending deprecation is added.

Regards,
Martin