[Python-Dev] float atime/mtime/ctime - a bad idea? (original) (raw)
Guido van Rossum guido@python.org
Wed, 16 Oct 2002 08:25:46 -0400
- Previous message: [Python-Dev] float atime/mtime/ctime - a bad idea?
- Next message: [Python-Dev] float atime/mtime/ctime - a bad idea?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 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 "timesarefloat" 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/)
- Previous message: [Python-Dev] float atime/mtime/ctime - a bad idea?
- Next message: [Python-Dev] float atime/mtime/ctime - a bad idea?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]