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