...

...

...

...

"MvL" == Martin v Loewis writes:

>> +1 on the latter idea. Since the st_mtime, st_atime, and >> st_ctime attributes, and the tuple-ish API are documented as >> returning ints, I think you shouldn't change that. Provide >> different field names for float values, e.g. f_mtime, f_ctime, >> f_atime, or maybe just mtime, atime, and ctime... ? MvL> The previous suggestion was st_mtimef, st_ctimef, ... Names which differ by one character at the end of the name are error prone, IME. Plus it makes stuff like dabbrev-expand harder to use. :) -Barry

BAW> Provide different field names for float values, e.g. f_mtime, BAW> f_ctime, f_atime, or maybe just mtime, atime, and ctime... ? Martin> The previous suggestion was st_mtimef, st_ctimef, ... Why not simply provide an alternative method, os.fstat()? Seems cleaner to me. The field names are hard enough to remember as it is... Skip

Skip Montanaro writes:

Martin> The previous suggestion was st_mtimef, st_ctimef, ...

Why not simply provide an alternative method, os.fstat()?

Because os.fstat already exists, and also has the option of either returning floating point time stamps or integer time stamps - just like os.stat and os.lstat. Regards, Martin

...

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/)

Barry:

So then why not just make this an optional argument flag on the os.stat() call itself? That way you could migrate some code at a different rate than other code (a global flag might be fine for your application, but break some 3rd party library you're using).

And Kevin:

Please don't! The global setting isn't sufficient since many of us access many 3rd party modules.

Most code doesn't care; most 3rd party code will work either way. Martin proposed adding an option to the stat() call itself first, but that seems a rather heavy-handed way to ensure backwards compatibility for such a very rare situation. If you are using a 3rd party library that breaks due to the floats, you can disable the floats until you've got time to fix it. You can live with the ints a little longer. --Guido van Rossum (home page: http://www.python.org/~guido/)

barry@python.org (Barry A. Warsaw) writes:

But you may end up ping ponging between floats and ints as you import new libraries into your app. If, as you surmise, most code won't care, then that won't be a real problem.

With Guido's most recent suggestion (put ints into the tuple), it is even more likely that nothing will break if floats are activated (we should investigate the two known incidents to find out whether they were using the tuple interface).

# do something requiring float times

I think this is a central point here: Why would anything *require* float times? If the system does not support subsecond timestamps, or Python does not expose that (e.g. Windows), you will get floats, but you won't get fractions of a second.

Maybe it won't matter in practice, but global state like that always tickles the gag reflex in me. ;)

I completely agree about reflexes and general feelings. However, we assume that this indeed won't matter in practice. Regards, Martin

With Guido's most recent suggestion (put ints into the tuple), it is even more likely that nothing will break if floats are activated (we should investigate the two known incidents to find out whether they were using the tuple interface).

I was using the tuple interface -- this code needed to work under Python 2.1.

I completely agree about reflexes and general feelings. However, we assume that this indeed won't matter in practice.

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

Guido van Rossum writes:

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.

Sounds good. Unless I hear otherwise, I'll add stat_float_times(bool). That still leaves the question of a migration plan, assuming that users, in general, would appreciate to silently get subsecond timestamps where possible. Here is a proposal: - 2.3: just add stat_float_times. In the documentation, warn that the value will change in the future. - 2.4: make stat_float_times(True) the default. Applications that break would need to add stat_float_times(False) in a central place. This has no phase were a warning is emitted, but any scheme that adds a warning means that the user first has to add something (to silence the warning), and then to remove something (when the default changes - although the option might stay forever). Regards, Martin

Kevin Jacobs writes:

...

Sounds good. Unless I hear otherwise, I'll add stat_float_times(bool).

Please don't! The global setting isn't sufficient since many of us access many 3rd party modules.

Why is that insufficient? As long as you have modules that require int time stamps, you can't switch to float time stamps. If you find you are using such a module, tell the module author about that, and wait for a corrected module.

Why not simply create properies that return the int/float versions from the same structure and store the float versions?

How can the property know whether to return an int or a float? Regards, Martin

Why break all modules when only one needs the old behavior? Think about how from __future__ import is set up.

Because this is IMO a *very* small change, for which I don't want to invoke such heavy guns. --Guido van Rossum (home page: http://www.python.org/~guido/)

...

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.

Sounds good. Unless I hear otherwise, I'll add stat_float_times(bool).

That still leaves the question of a migration plan, assuming that users, in general, would appreciate to silently get subsecond timestamps where possible. Here is a proposal:

- 2.3: just add stat_float_times. In the documentation, warn that the value will change in the future. - 2.4: make stat_float_times(True) the default. Applications that break would need to add stat_float_times(False) in a central place.

This has no phase were a warning is emitted, but any scheme that adds a warning means that the user first has to add something (to silence the warning), and then to remove something (when the default changes - although the option might stay forever).

Sounds good. I wonder if we could let the tuple-ish interface return ints forever (or until it's no longer supported). --Guido van Rossum (home page: http://www.python.org/~guido/)

...

I wonder if we could let the tuple-ish interface return ints forever (or until it's no longer supported).

That would not be easy to implement. The structseq type does not support unnamed sequence members (yet), which we'ld need: the int members would have only indices, and the float members only names.

It probably could be made work by allowing NULL names in a PyStructSequence_Field. I'll try to do this.

That sounds good to me. Or you could "subclass" the PyStructSequence class with something that special-cases the st_?time attributes. --Guido van Rossum (home page: http://www.python.org/~guido/)

"M.-A. Lemburg" writes:

If you're suggesting a new API, why not have it return one of the new datetime objects ?

Wouldn't that require to implement this type first? Regards, Martin

If you're suggesting a new API, why not have it return one of the new datetime objects ?

That would require much more changes to the user code to use the new feature. And in many cases a basic timestamp is just what you need -- all you usually do is comparing them, occasionally printing them, and both are done just as easily using the int or float form. --Guido van Rossum (home page: http://www.python.org/~guido/)