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

Guido van Rossum guido@python.org
Wed, 16 Oct 2002 08:25:46 -0400


> > 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?

I added int() around the st_mtime reference, because there's no
"OFBTree" data type, and because second resolution was good enough.

> > 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.

Agreed, but I don't like adding and then deleting a "temporary" new
argument to stat() and fstat().

In this particular case, I think having a global flag should be good
enough.  We can easily rig the standard library not to depend on its
value.  It should be settable by calling a function, e.g.

  os.stat_times(int)

or

  os.stat_times(float)

If you think passing the actual type objects is too cute, we can call
it stat_float_times() and pass a bool.

Without an argument it could return the current status, with the twist
that if the platform doesn't support float times it will always return
int.

Or maybe we can make it return the precision.

--Guido van Rossum (home page: http://www.python.org/~guido/)