[issue27916] Use time.monotonic instead of time.time where appropriate

2019-03-11 Thread Cheryl Sabella
Cheryl Sabella added the comment: multiprocessing was changed to use time.monotonic in issue 34054. Based on the other feedback on this thread, I'm going to close this. -- nosy: +cheryl.sabella resolution: -> rejected stage: -> resolved status: open -> closed _

[issue27916] Use time.monotonic instead of time.time where appropriate

2016-08-31 Thread Ville Skyttä
Ville Skyttä added the comment: Thanks for the explanation, understood. However, I don't think it would be terribly difficult to demonstrate that these changes do address actual pains(*) in the situations they're supposed to address them. And the pains in question might in real world occur qui

[issue27916] Use time.monotonic instead of time.time where appropriate

2016-08-31 Thread Guido van Rossum
Guido van Rossum added the comment: I mostly adhere to the rule of thumb "if it ain't broke, don't fix it". So I would only endorse such changes if they address actual pain, rather than possible pain. Note that that rule of thumb was born out of worry about another possible pain: the observation

[issue27916] Use time.monotonic instead of time.time where appropriate

2016-08-31 Thread Ville Skyttä
Ville Skyttä added the comment: It is not a wholesale search and replace, I have checked each change. There are a lot of places in the tree where monotonic is not appropriate, and those should not be included in the patch. But there is always the possibility that I've missed something, and it'

[issue27916] Use time.monotonic instead of time.time where appropriate

2016-08-31 Thread Guido van Rossum
Guido van Rossum added the comment: asyncio already uses monotonic. The only place patched is a test utility and I don't care either way. But I do think this is not a good patch to do in general. -- ___ Python tracker

[issue27916] Use time.monotonic instead of time.time where appropriate

2016-08-31 Thread Raymond Hettinger
Raymond Hettinger added the comment: Some of these look gratuitous to me, possibly a wholesale search and replace without detailed consideration of each change. For example, the quick informational timing in random.py does not have any downside for using the regular time.time(). The changes

[issue27916] Use time.monotonic instead of time.time where appropriate

2016-08-31 Thread Ville Skyttä
New submission from Ville Skyttä: For better immunity against system clock changes. -- files: monotonic.patch keywords: patch messages: 274036 nosy: scop priority: normal severity: normal status: open title: Use time.monotonic instead of time.time where appropriate type: enhancement Adde