[Python-Dev] float atime/mtime/ctime - a bad idea? (original) (raw)

Martin v. Loewis martin@v.loewis.de
16 Oct 2002 08:08:29 +0200

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