> > 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4